current startup time standings

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).

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
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
[hidden email]
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
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Which software versions did you test? I'm especially interested in the ruby
version number.

At 01:35 PM 12/18/2006 +0100, Paolo Bonzini wrote:


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

J Pfersich wrote:
> Which software versions did you test? I'm especially interested in the
> ruby version number.

Python 2.5
ruby 1.8.4 (2005-12-24) [powerpc-darwin]
% puts ${tcl_version}
8.4
This is perl, v5.8.6 built for darwin-thread-multi-2level

Note that this cost will occur just once if you're using
mod_python/mod_ruby/mod_perl.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk