Ben Giddings wrote:

> Mauricio FernáÏdez wrote:
>> IIRC the "interpreter" (AST based) will be dumped.
> 
> Hmm, will this affect the startup time?  My understanding is that one of
> the reasons Java is so slow to start up is the VM setup.

No bytecode should not slow things down. Ruby har a decent sized runtime
library - this must be loaded no matter how you execute the code. An
efficient bytecode interpreter may speed up startup time because you can
skip the parsing. However, Ruby is currently loading Ruby source files on
demand. In a bytecode interpreter it might load more code than it would
have done in the current interpreter - this could affect startup time.

OCamls bytecode is very fast, its runtime engine is comparatively small and
there is no noticable startup overhead at all. I think Parrots non-stack
based VM might also be very fast but it is difficult to predict - it also
depends on the quality of the byte code generating compiler (affects
runtime not startup time). OCaml bytecode has 10 years of development
behind it or so.

Java is well ... Java. I guess they load 100-200 class libraries
unnecessarily - my guess is that recent Java implementations have improved
significantly although I'm not using Java that much. I'm trying out the
Jakarta FOP XSL-FO processor written in Java, and it starts up fast enough.

Mikkel