> Time millisecondsToRun:
>    [Interpreter
>      translate: 'interp.c'
>      doInlining: false]
> 
> I get about 85 seconds for the old VM and 86 seconds for the 
> new one.  From the tinyBenchmarks methods, I'd have expected
> a much better performance. 

The interpreter translation is almost never affected by any increase in the
tiny benchmarks. We've noticed that a long time ago.

> I spyOn-ed the code so see where most time is spend:
> 
> 19.1% {19817ms} Symbol class>>intern:
> 14.7% {15252ms} StandardFileStream>>next
> 11.9% {12347ms} CrLfFileStream(StandardFileStream)>>nextPutAll:
> 7.1% {7367ms} CrLfFileStream(Object)>>retryWithGC:until:
> 
> Most time is spend creating symbols.  That's pure smalltalk 
> stuff.  Then a large amount of time is spend with file I/O. 
> Why does this read files? 

For getting the method source for all the methods to translate.

> I thought, it's writing C source? 

It is - #nextPutAll: comes in third.

> Is it using temporary files? Whatever, 
> this partly explains why faster bytecode interpretation 
> doesn't have such a big impact.  And it also shows that for
> the overall performance it's at least as important to have
> fast I/O.

Absolutely. We could get a big speed advantage during I/O given that we'd
use a buffering file stream (rather than the current unbuffered version).
Anyone care to do it?!

> Last but not least, I wonder about retryWithGC:until:. 
> This is called either via ClassBuilder>>fixGlobalReferences 
> (unlikely) or during opening, renaming or deleting files. 
> That that's funny.  I never thought that it would take 
> more than 7 seconds to open or delete files...

Interesting. Let me have a look at this.

  - Andreas