Your comments about 28 jars means that the pkg manager will cache the jars on the first startup which takes quite a bit of time to process for the first run.
If you only use full class imports, you can skip the package scanning altogether. Set the system property python.cachedir.skip to true and it should start much more quickly than it currently does (unless you are using jythonstandalone.jar which skips caching already)
Some projects have embedded nailgun with success as well
What version of the jvm are you running?
When running a 64-bit-only Hotspot JVM, there is no client mode. You can get the same effect as client mode by passing two flags: -XX:+TieredCompilation -XX:TieredStopAtLevel=1
Jim's suggestions with bootpath and -S are also good.
I've experimented with -Xverify:none with varying success as well in the past.
But nailgun seems to give the most bang for your efforts if that integration is something you can consider.
-WOn Jun 17, 2013 12:39 PM, "Jim Baker" <firstname.lastname@example.org> wrote:TL;DR - use the bootpath, this is the easiest winOn Mon, Jun 17, 2013 at 9:28 AM, Jim Purbrick <email@example.com> wrote:
On 4 June 2013 14:22, Walter Chang <firstname.lastname@example.org> wrote:Yes: my test command ran slightly slower (32s vs 30s in server mode)
> Most of jython's startup overhead comes from:
> -jvm startup
> Did you try starting the jvm in client mode?
How do I do this and still have java find the jars when it needs them?
> -initial caching of jars in your classpath bootpath
> pruning your classpath does help a bit on initial runs.
Currently I have 28 jars passed to java via "-classpath".Use -Xbootclasspath/a as an alternative to -classpath for those jars (FWIW, I'd recommend looking at the jython script for this and other similar environmental setup). This is probably the easiest way to get a significant win on Jython startup performance by avoiding the overhead of class verification.So$ time jython27 -c "print 42"42real 0m1.363suser 0m1.976ssys 0m0.150svs$ time jython27 --boot -c "print 42"42real 0m0.919suser 0m1.212ssys 0m0.115s(jython27 is my alias to the jython script running against Jython trunk; lastly all numbers are reported from my laptop... differences are certainly significant and stable)I'd like to avoid jdk specific optimizations if possible.
> -try the openjdk 8 jigsaw preview releases
> this will allow you to shrink your jvm somewhat. Note that openjdk hotspot
> is slower than the oracle version.
I tried passing -Xmx600m, -Xmx300m and -Xmx128m to java and saw nearly
> -jvm startup memory options
> a big heap slows the startup of the jre. Small builds probably can start
> with less memory
identical run times compared with the default -Xmx1000m (but
significantly lower memory usage)
Are there any other options I can try? Would using the
PythonInterpreter API and/or PyObjects APIs instead of JSR-223 help?JSR223 support and PythonInterpreter implement similar facades to the Jython runtime, therefore I would not expect even observable performance differences.
Could I prune Python libraries that aren't used out of Jython to
improve performance?The closest to this is -S (don't import site, and those dependencies) in the jython startup script, however this path is not used by JSR223/PythonInterpreter. Savings of ~250 ms in my testing:$ time jython27 --boot -S -c "print 42"42real 0m0.673suser 0m0.861ssys 0m0.093s- Jim