Hi,

I'm working on profiling squeak/etoys for the olpc project.

It seems to me that bytecodes cases in the interpret function
(in /platform/unix/src/vm/interp.c) are not ordered in respect to
the probability of their execution.

Here is a graph for reference (more games in Etoys have
the same pattern):
http://www.bodhidharma.info/instructions.pdf

What I did so far is changing the `256 cases switch' statement to an array
of function pointers like (*exec_bytecode_funcs)[bytecode_id](
...shared data... );
The process was automated with a python script and that needed a little bit
of code cleaning; after some testing I couldn't trigger any sort of
bug in the new code.


if we assume a constant time T both for the execution of every
[if !(right_case) jump next_case] in the old code and for the
function pointer dereference in the new code there is a 10000% gain
for the task of calling the right action for a given bytecode
(also given the distribution showed in the graph linked above).

In my tests this is a 20/30% win over the interpret routine timings
for different games
in etoys.

I appreciate any comments on this work.
Maybe it could be done better than this ?

Thanks,
Riccardo