Created
July 4, 2011 19:14
-
-
Save cotto/1063804 to your computer and use it in GitHub Desktop.
profiling thoughts
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So, we need some kind of profiling. imcc is nearly worthless concerning line | |
numbers*, so that information is basically useless until we're on PIRATE or | |
someone rides in with shining armor and fixes imcc once and for all. For the | |
time being, ignoring imcc's line numbers is the best way forward. | |
That leaves us with sub-level profiling. pmichaud has already done some work | |
here to great effect with a quick and dirty hack, so this more limited form of | |
profiling will still allow useful work to be done. | |
The question now shifts to what this sub-level profiler will look like. | |
Something that can produce callgrind-compatible output is nice, but not at all | |
vital. It'll probably be easier to get callgrind-compatible output going for | |
something simpler, though it'll still be a bit tricky. The priority is to get | |
something useful as quickly as possible, then iterate it into progressively | |
more menacing and terrifying forms, not entirely unlike a final boss. | |
The most basic possible sub profiler would be one that spits out a short | |
message each time a sub is called, allowing some other tool to do | |
post-processing on the output. A slightly more complicated but much more | |
useful version would also print the time from a high-resolution timer every | |
time the current sub changed. This would require some smarter post-processing | |
or some slightly non-trivial smarts in the profiler, but it'd get the job done | |
and provide a viable minimum profiler. | |
The next question is what kind of structure the thingy will have. A runcore is | |
the most sensible way to do it based on how it's been done in the past, but I'm | |
leary of runcore proliferation. Still, that's the best way to get something | |
done quickly. I'm not sure if there are any good alternatives. | |
The alternative is to create an alternate post-processing tool for the current | |
profiling runcore's output. This means we'd lose the optimization | |
possibilities of a simpler sub-level profiler, but it'd be a lot less work and | |
could probably be knocked out in a few days. | |
[*] Regarding line numbers, imcc shifts between being almost usable and nearly | |
worthless as various people try to fix it. It was almost usable while I was | |
working on the profiling runcore, but more recently soh_cah_toa has been having | |
unending trouble getting any non-trivial amount of useful information from | |
imcc's line number annotations. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment