NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 650 - Java weaver for Jython scripting is painfully slow, but only in Windows
Java weaver for Jython scripting is painfully slow, but only in Windows
Status: RESOLVED WONTFIX
Product: Fiji
Classification: Unclassified
Component: Other
unspecified
PC Windows
: P5 major
Assigned To: ImageJ Bugs Mailing List
Depends on:
Blocks:
 
Reported: 2013-08-11 21:21 CDT by unidentified.thing
Modified: 2013-08-12 09:53 CDT
1 user (show)

See Also:

Description unidentified.thing 2013-08-11 21:21:26 CDT
I've tested the weaver (weaver.inline from fiji.scripting) on three different OS with comparable hardware, sometimes in dual boot: Mac OS X, Linux (Debian and Fedora), and Windows (7 and XP). Only in Windows do I get awful performance. The other two seems fine.

The performances I'm talking about are up to 10 seconds for simple functions to (apparently) compile to java bytecode. I'm saying this because I've put some print statements around the weaver and it seems that the bottleneck is happening as the weaver is declared, not when it's called. This is ridiculous, as setting up the weaver takes a hundred times longer than it does to execute the statements it contains. I might as well drop this useless weaver entirely, as I need my plugin to be portable on every OS. But I'm not really happy at having to rewrite all of my plugin, in a much slower language at that!

In comparison, the other OS are well within < 1 second in execution time.
Comment 1 Johannes Schindelin 2013-08-12 09:53:20 CDT
Hello, unidentified.thing.

The problem is Windows' filesystem performance, especially when being hampered further by a (necessary) Anti-Virus.

There are loose plans to rewrite the weaver completely (making it independent from Jython, using a more efficient, in-memory compilation), but that plan is already over a year old and pushed back all the time by more pressing problems.

In the short run: work around it by using Windows only as an end-user platform, and develop on Linux instead (which has by far the best filesystem performance of the 3 big operating systems): The compiled code should be reused if the source is unmodified, so filesystem performance matters more while developing code.