Re: [Jython-users] jython-2.1b1 startup time

[<bc...@wo...>]

[Jan Wender on slow startup for 2.1b1]

>I also noticed it on Unix systems:
>Linux (MSC.2001Aug on i686)
>
>ian@leo tmp > time jython -c 'import sys; sys.exit()'
>
>real    0m4.859s
>user    0m3.370s
>sys     0m0.100s
>ian@leo tmp > time ~/jython-2.1a3/jython -c 'import sys; sys.exit()'
>
>real    0m1.964s
>user    0m1.740s
>sys     0m0.090s
>
>DEC Alpha OSF1 alpha V4.0
>ian@alpha 200gui > time jython -c 'import sys; sys.exit()'
>
>real    0m10.416s
>user    0m9.703s
>sys     0m0.383s
>ian@alpha 200gui > time ~/jython-2.1a3/jython -c 'import sys; sys.exit()'
>
>real    0m2.498s
>user    0m2.072s
>sys     0m0.313s
>

>> Which JVM?
>Linux:
>ian@leo tmp > java -version
>java version "1.3.1_01"
>Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
>Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
>
>Alpha:
>ian@alpha 200gui > java -version
>java version "1.3.0"
>Java(TM) 2 Runtime Environment, Standard Edition
>Classic VM (build 1.3.0-1, native threads, jit)
>
>
>> Maybe its scanning CLASSPATH jar files. Do you have write access to the
>> "cachedir" directory?
>
>Yes, and it has not scanned the jar files, because I called it twice and =
>took only the second timing.

I'm sure it have scanned the jar files. The question is whether jython
wrote the scan result info cachedir/packages. Is the cachedir/packages
directory empty or non-existing?

The problem was fixed in Stefan's case by running a chmod on the files
and subdirectories in cachedir.

>>
>> If your JVM have some kind of verbose options, try running with
>> different kind of verbosity enabled. Maybe it will give some clues about
>> what it is doing in that time.

>I have attached two logfiles, produced with=20
>scjava -verbose -Dpython.home=3D"/home/ian/jython-2.1a3" -classpath "/hom=
>e/ian/jython-2.1a3/jython.jar:$CLASSPATH" "org.python.util.jython" >loga3
>resp.
>scjava -verbose -Dpython.home=3D"/usr/local/jython-2.1b1" -classpath "/us=
>r/local/jython-2.1b1/jython.jar:$CLASSPATH" "org.python.util.jython" >log=
>b1
>
>CLASSPATH is /home/ian/venus/200gui/gui/jar/xmlrpc-a.jar in both cases.
>
>The b1 loads a lot (36) more libraries than the a3, this is probably causing
>the delay.

The vast majority of the additional classes is the "sre" module. This is
now loaded by the "os" module which is loaded by the "site.py" file.

We might have to rethink the use of re's in javaos.py, but for now I
have a very hard time believing that we can measure the overhead of an
additional 36 classes with a stopwatch.

The prime suspect is still the lack of caching of the jar scan result.
Try to remove cachedir just to verify that the startup time become
significantly larger.

regards,
finn