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)


On Jun 17, 2013 10:09 PM, "Walter Chang" <> wrote:

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.


On Jun 17, 2013 12:39 PM, "Jim Baker" <> wrote:
TL;DR - use the bootpath, this is the easiest win

On Mon, Jun 17, 2013 at 9:28 AM, Jim Purbrick <> wrote:
On 4 June 2013 14:22, Walter Chang <> wrote:
> Most of jython's startup overhead comes from:
> -jvm startup
> Did you try starting the jvm in client mode?

Yes: my test command ran slightly slower (32s vs 30s in server mode)

> -initial caching of jars in your classpath bootpath
> pruning your classpath does help a bit on initial runs.

How do I do this and still have java find the jars when it needs them?
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.


$ time jython27 -c "print 42"

real 0m1.363s
user 0m1.976s
sys 0m0.150s


$ time jython27 --boot -c "print 42"

real 0m0.919s
user 0m1.212s
sys 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)

> -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'd like to avoid jdk specific optimizations if possible.

> -jvm startup memory options
> a big heap slows the startup of the jre.  Small builds probably can start
> with less memory

I tried passing -Xmx600m, -Xmx300m and -Xmx128m to java and saw nearly
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"

real 0m0.673s
user 0m0.861s
sys 0m0.093s

- Jim