current startup time standings

Paolo Bonzini wrote:
> On my machine, for 200 runs:
> 
> Python   user    0m7.066s  sys     0m14.691s  avg  
108ms
> gst      user    0m8.500s  sys     0m7.240s   avg   
78ms (no JIT)
> PHP      user    0m8.208s  sys     0m5.432s   avg   
68ms
> Ruby     user    0m2.630s  sys     0m2.761s   avg   
26ms
> Tcl      user    0m1.765s  sys     0m3.190s   avg   
24ms
> Perl     user    0m0.686s  sys     0m1.879s   avg   
12ms
> 
> I'll see if I can do something more, but it's already
pretty good (40ms 
> in GST are spent in the interpreter, 38 loading the
binary image).

Nice. Do you have any feel for how much these figures would
change 
depending on what's in the image? In other words, how will
an image 
loaded with a couple of libraries compare with a basic
image?

Mike


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Nice. Do you have any feel for how much these figures
would change 
> depending on what's in the image? In other words, how
will an image 
> loaded with a couple of libraries compare with a basic
image?

There are two factors:

1) image loading time.  With the copy-on-write code, the
startup time 
only depends on the number of OOPs, not on the size of the
objects in 
the image.  However, huge libraries such as GTK+ will create
three or 
four OOPs for each method (CompiledMethod, MethodInfo, 
CFunctionDescriptor, possibly a Symbol too).  Another factor
is the 
number of symbols in the image, which slows down 
init_dictionary_on_image_load (this takes about 8ms on a
default image 
and is the next candidate for a speedup...).

2) #returnFromSnapshot execution time.  Right now it is
close to zero, 
but the code in DLD is not efficient at all, because it
dlopens all the 
libraries at startup: it can be sizable for something like
GTK+.  I did 
not change it yet just because it does not run at all in the
default 
image.  It would be interesting to attach a library name in
a 
CFunctionDescriptor, and dlopen the libraries lazily; you
may give it a 
try.  However, if you'd find out that dlopening takes time
even for 
(say) GNU Smalltalk's own tcp.so, I'd seriously consider
moving tcp.so 
to the main executable.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk