Skip to content

Instantly share code, notes, and snippets.

@cotto
Created July 4, 2011 19:14
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save cotto/1063804 to your computer and use it in GitHub Desktop.
Save cotto/1063804 to your computer and use it in GitHub Desktop.
profiling thoughts
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