Remove accidentally added file.
This commit is contained in:
Vincent St-Amour
parent
79c265ef89
commit
ebd2e35600
|
|
@ -1,125 +0,0 @@
|
|||
OC TODO
|
||||
|
||||
Oh, also the optimization-coach-callback should probably not erase the
|
||||
user's interactions (what it currently does).
|
||||
Instead, it would be better to do something like what check syntax
|
||||
does, namely create another control embedded in the window that
|
||||
contains the error message (and a "hide" button).
|
||||
Robby
|
||||
|
||||
|
||||
|
||||
tool-tips instead of popups
|
||||
|
||||
have highlights to the end of lines
|
||||
to capture right-clicks properly, maybe ask canvas directly if event is in
|
||||
the right place. I dunno.
|
||||
The way things are set up in the editor, there are kind of "two
|
||||
regions" of coordinates. The editor knows only about those pixels that
|
||||
go as far as the widest line in the editor. After that, you have to
|
||||
use the canvas% object that the editor is inside. I forget how all
|
||||
this goes, but I think you should try poking around in the canvas when
|
||||
you get #f back or something like that. -- Robby
|
||||
maybe look at ryan's code: macro-debugger/syntax-brower/text.rkt, ~l382
|
||||
|
||||
move to toplevel collect once we figure out long-term way to invoke OC
|
||||
at that point, move docs to their own document
|
||||
that involves changing a #:tag, or something, that Robby put there
|
||||
|
||||
for inlining, ignore when fuel is too low, etc. what we say we do in the paper
|
||||
|
||||
for each pop-up entry, have button: "show me where" that circles (not
|
||||
highlights) the piece of code in the defs window
|
||||
|
||||
merge opts too, have goodness measure, and multiple shades of green
|
||||
when merging opts, highlight (in green, in popup) the specific
|
||||
operations that are optimized
|
||||
|
||||
set-clickback can do highlighting, there's a style delta arg
|
||||
good to know if I go back to sth like that
|
||||
|
||||
run OC in a separate place, using the online compilation API?
|
||||
|
||||
inlining recommendations: point to racket/performance-hint ?
|
||||
|
||||
TR recommendations: point to exact->inexact, flsqrt, etc
|
||||
|
||||
add a link/button to popups that circles code (of a popup entry) in defs win
|
||||
|
||||
have inliner logs be in sexp format
|
||||
-> argh, paths are not readable
|
||||
|
||||
paper says we use ratio of inlinings and missed inlining. we currently
|
||||
just use subtractions
|
||||
also, all kinds of opts share the same scale
|
||||
checkboxes to enable / disable each may alleviate the problem
|
||||
|
||||
better integrate inliner logging with what matthew already had?
|
||||
;; TODO should have o-o-f that missed by only a little count for less. we mention in paper
|
||||
;; TODO also, change recommendation depending on how close the misses were, give an idea of how much the function needs to be reduced
|
||||
|
||||
move structs defs from optimizer/logging.rkt to PR. and maybe other things too
|
||||
|
||||
;; TODO don't show checkbox for TR opts when not in TR
|
||||
|
||||
;; TODO ignore all loops (heck, maybe even identifiers that contain
|
||||
"loop", since they pretty much only ever add noise
|
||||
-> (months after original comment): is it still as bad with
|
||||
unrollings considered separately? yeah, probably
|
||||
+ ;; TODO -> so maybe, if there are unrollings at all, don't say anything at all!
|
||||
;; TODO other heuristic: discard events that have to do with identifiers
|
||||
not in the program (or better, not in the region that would be
|
||||
highlighted). would get rid of procs introduces by macros (for-loop,
|
||||
stuff from match, etc.)
|
||||
|
||||
|
||||
|
||||
;; `f' is a loop. We ignore anything beyond the first inlining
|
||||
;; in `g'.
|
||||
+ ;; TODO ignore beyond, or ignore the whole thing? currently, the latter is implemented
|
||||
(apply
|
||||
append
|
||||
(for/list ([site (in-list inlining-sites)]
|
||||
|
||||
|
||||
+;; TODO information is better targeted w/o inliner info. The problem is that
|
||||
+;; inlining basically highlights entire functions, and pretty much all of them.
|
||||
+;; This means that any finer grained regions in the function get merged.
|
||||
+;; TODO solution: highlight only function name -- i.e. (define (_f_ x) ...)
|
||||
+;; or, if lambda, highlight the lambda itself. etc.
|
||||
+;; TODO OOPS: doesn't work with stuff like for-loop, which is introduced by expansion
|
||||
+;; TODO maybe a better solution is better handling of nesting. show nested regions
|
||||
+;; (with the inner one being redder, or red as opposed to green, etc.), and only when
|
||||
+;; clicking on the inner one do you get the whole thing (inner and outer)
|
||||
|
||||
|
||||
we can use unrollings to determine whether a function is a loop or not!
|
||||
conservative, but sounds like it would work!
|
||||
if a function is unrolled, we assume it's a loop.
|
||||
THEN
|
||||
if we're in a loop, we can do more aggressive recommentations:
|
||||
- struct -> vector
|
||||
- hoist parameter-using funcs (e.g. print / random, if not passed the
|
||||
port / prng arg, will implicitly do a parameter lookup. _but_, they
|
||||
can also be passed the port / prng. if you're in a loop, you probably
|
||||
want to lookup the param once, outside the loop, then pass it to print
|
||||
/ random)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
future opts to report:
|
||||
|
||||
hidden parameterizations (e.g. write, when called, looks up value for
|
||||
current-output-port, if you call it in a loop, you look up value n times.
|
||||
write also takes an extra port argument. if you look up current-output-port
|
||||
yourself once outside the loop, then pass that to write every time, win.)
|
||||
|
||||
where closures get allocated
|
||||
|
||||
Loading…
Reference in New Issue
Block a user