A note on JVM performance

[Grant Harris]

This article, Java vs C++ "Shootout" Revisited
(<a href="http://java.sys-con.com/node/45250##">http://java.sys-con.com/node/45250##), makes a strong case to refute the
still prevalent myth that Java is slow.  "[E]ven with JVM startup time, Java
is still faster than C++ in many of these tests."

It also points out that "no one should ever run the client JVM when given
the choice... Unfortunately, Java applications and applets run by default in
the client VM," Lea observes. "The Server VM is much faster than the Client
VM, but it has the downside of taking around 10% longer to start up, and it
uses more memory."

All you need to do is add -server to the java.exe arguments.  I'd like to
hear if anyone finds a marked improvement in using ImageJ.
Cheers.
-- Grant Harris, MBL

[ctrueden]

Hi Grant,

Studies disagree on exactly how much slower Java is than C++ and in what
ways. People like to broadly generalize about these technologies when
unfortunately it can't really be done objectively.

I wrote up a short bit on Java vs. C++ on the LOCI software web site:

  http://www.loci.wisc.edu/ome/faq.html#java

People like to cite the Shootout article but it's already five years old. A
lot changes in that time when it comes to software, so such articles are
often immediately out of date.

Still, I agree that Java's performance is quite reasonable for most
applications and people should think carefully about their application's
needs before resorting to C++ for performance reasons.

-Curtis

On Fri, Jun 12, 2009 at 12:10 PM, Grant Harris <[hidden email]> wrote:

> This article, Java vs C++ "Shootout" Revisited
> (<a href="http://java.sys-con.com/node/45250##">http://java.sys-con.com/node/45250##), makes a strong case to refute the
> still prevalent myth that Java is slow.  "[E]ven with JVM startup time,
> Java
> is still faster than C++ in many of these tests."
>
> It also points out that "no one should ever run the client JVM when given
> the choice... Unfortunately, Java applications and applets run by default
> in
> the client VM," Lea observes. "The Server VM is much faster than the Client
> VM, but it has the downside of taking around 10% longer to start up, and it
> uses more memory."
>
> All you need to do is add -server to the java.exe arguments.  I'd like to
> hear if anyone finds a marked improvement in using ImageJ.
> Cheers.
> -- Grant Harris, MBL
>

[Albert Cardona]

Grant Harris wrote:
> All you need to do is add -server to the java.exe arguments.  I'd like to
> hear if anyone finds a marked improvement in using ImageJ.
> Cheers.
> -- Grant Harris, MBL
>  


More performance hints:

* When working with large heap sizes, be aware that the initial minimum
heap size (defined by -Xms) will be duplicated until it reaches the
maximum heap size (as defined by -Xmx). This heap duplication is costly
and sometimes generates OutOfMemoryError.
 To avoid it, launch the JVM with fixed heap size, for example 4Gb:

  java -Xms4000m -Xmx4000m


* In multicore CPUs, switch on the incremental garbage collection, which
helps immensely to avoid heap buildup and long pauses:

  java -Xincgc


* Disable explicit calls to System.gc(), which trigger the garbage
collection for no good reason (that was only useful in very old,
not-so-effective JVMs):

  java -XX:+DisableExplicitGC


For fiji, combine all the above with:

  ./fiji -server -Xms4000m -Xmx4000m -Xincgc -XX:+DisableExplicitGC --

(Note the double hyphen at the end, to separate JVM arguments from
ImageJ arguments.)


Albert

--
Albert Cardona
http://albert.rierol.net

[Albert Cardona]

Aryeh Weiss wrote:
> Dear Albert,
>
> How can I apply these option to Fiji (and ImageJ) on a mac?



As I explained here:

 
http://imagejdocu.tudor.lu/doku.php?id=howto:general:imagej_performance_tuning

... you need something like:

<key>VMOptions</key>
<string>-Xms4000m -Xmx4000m -Xincgc -XX:+DisableExplicitGC -server</string>


.. in your ImageJ.app/Contents/Info.plist file.

If the VMOptions entry is not there, just add it.

Hope that helped.

Albert

--
Albert Cardona
http://albert.rierol.net