Improved usability of profiler tool

Factor 0.90 introduced a profiler:

enable-profiler

[ ... ] profile

disable-profiler

The problem was that the enable-profiler/disable-profiler calls would recompile all words to add/remove a prologue which incremented the word's call count. The point here was that we only want a profiler prolog when we're actually profiling, and not all the time, because of the time overhead in testing the global profiling flag on every word invocation. However, in practice this meant that I rarely used the profiler, because recompiling all words takes a minute or two.

Today I changed the implementation to be much more clever. Now, words are always compiled with profiler prologues. The trick is that unless the profiler is enabled, the entry point of the word points at just after the profiler prolog. When the profiler is enabled, the entire code heap is scanned, and pointers to words are updated to point to before the prolog.

Seems like a pretty obvious idea in hindsight. I know I'll end up using the profiler a lot more now. I also want to experiment with using it to implement new tools, such as test coverage. Basically you'd run unit tests for a certain vocabulary with the profiler enabled, then look at what percentage of words in that vocabulary were called. This won't test branch coverage, but Factor words tend to be short, so a coarse word-oriented coverage tool can still be useful here.