how much can a native compiler improve the performance of a java application?

Thread view:

Norbert Ganslmeier - 12 Jul 2004 18:58 GMT

Hello,

we have a customer with low-end machines who complains very much about the
starting time of an application of us. I dont't know the exact configuration
of the clients but i think the bad perfrmance is because the client has too
few memory and has to swap when the jvm starts.

Could a native compiler like Excelsior JET be a solution or would the
imporvement be only marginal?

Anyone who has experience in this topic?

Thank you in advance!

Reply to this Message

Mike - 12 Jul 2004 19:19 GMT

> Hello,
>
[quoted text clipped - 9 lines]
>
> Thank you in advance!

Try gcj.

Reply to this Message

Roedy Green - 12 Jul 2004 19:49 GMT

>Could a native compiler like Excelsior JET be a solution or would the
>imporvement be only marginal?

You can find out easily enough. There is a free evaluation/personal
version. I find they start quite a bit more quickly. That is the most
noticeable difference.

see http://mindprod.com/jgloss/jet.html

I believe Sun uses a DLL. If that DLL stays loaded (when you have lots
of RAM) then subsequent starts are faster. Sun is mostly interested
in server side where fast startup is not an issue.

Signature

Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Reply to this Message

Artur Biesiadowski - 12 Jul 2004 21:11 GMT

> Could a native compiler like Excelsior JET be a solution or would the
> imporvement be only marginal?

It can be a solution as far as startup time is concerned. It won't help
much in other areas - program performance after warming up, memory
usage, etc.

For me, static compilers are more deployment tools than performance
solutions.

Artur

Reply to this Message

Roedy Green - 12 Jul 2004 21:23 GMT

>It can be a solution as far as startup time is concerned. It won't help
>much in other areas - program performance after warming up, memory
>usage, etc.

Have you done any experiments with Jet?
It does some quite elaborate optimisations. It does stack allocation
of objects. It prunes out code you don't use.

Deployment is the bug bear with it. You need to install the JVM and
the Jet compiled DLLs of that JVM. Unlike Java the version match must
be bang on. In practice this means reinstalling every client with
every app every release of Jet.

Signature

Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Reply to this Message

Artur Biesiadowski - 12 Jul 2004 21:35 GMT

> Have you done any experiments with Jet?
> It does some quite elaborate optimisations. It does stack allocation
> of objects. It prunes out code you don't use.

Long time ago - around 3 years as far as I remember. Both jet and
Hotspot came a long way since then, but I know a few people who used it
recently and still are not shocked by raw throughput.

> Deployment is the bug bear with it. You need to install the JVM and
> the Jet compiled DLLs of that JVM.

AFAIK, as long as you don't use AWT/Swing, you can create standalone
executable using JET, without dependency on installed JDK. All server
code, SWT programs, LWJGL games can be deployed this way.

Artur

Reply to this Message

Roedy Green - 12 Jul 2004 22:18 GMT

>AFAIK, as long as you don't use AWT/Swing, you can create standalone
>executable using JET, without dependency on installed JDK. All server
>code, SWT programs, LWJGL games can be deployed this way.

Yes, that is called JetPerfect. To use it, you must first compile
statically, then exercise the code to collect any dynamically loaded
classes, then decide just what else you want included, e.g. other
timezones, other locales. Then you do a global optimisation that may
take a hour where it considers the app as a whole for optimisation.

This final optimisation is much slower than the usual compile.

The evaluation version does not have JetPerfect.

There are many ways to use the product. In some, you dynamically load
classes and statically compile them on the fly.

Signature

Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Reply to this Message

LDV - 13 Jul 2004 07:48 GMT

> The evaluation version does not have JetPerfect.

The evaluation version has all features of the Pro Edition, including
JetPerfect, JIT compiler, executable image optimizer and more.

It is Excelsior JET Personal Edition that does not have all these.

LDV

Reply to this Message

Roedy Green - 13 Jul 2004 08:42 GMT

>The evaluation version has all features of the Pro Edition, including
>JetPerfect, JIT compiler, executable image optimizer and more.
>
>It is Excelsior JET Personal Edition that does not have all these.

Quite right. I had it correct on my website.
http://mindprod.com/jgloss/jet.html

The evaluation edition gives you 60 days to play.

Signature

Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Reply to this Message

Thomas Maslen - 13 Jul 2004 01:42 GMT

[...]

>we have a customer with low-end machines who complains very much about the
>starting time of an application of us. I dont't know the exact configuration
>of the clients but i think the bad perfrmance is because the client has too
>few memory and has to swap when the jvm starts.

It's also possible that the client has enough memory and the delay you're
seeing is just Java class-loading time in JDK 1.2, 1.3 and 1.4. Of course
the best approach would be to get some real data (e.g. use whatever tools
you have on the operating system to see whether it really is swapping or
not). But one quick experiment that you might perform is to try running
JDK 1.5 (or 5.0 or whatever it's called this week), because it has some
magic that's designed to make startup faster.

Oddly enough, another possibility could be that you have made the Java
maximum heap size (-Xmx) a bit too *small*, so the JVM is spending all
its time garbage-collecting, trying to coalesce the free space.

Intuition can be misleading. Get some real data if you can.

Thomas Maslen
maslen@pobox.com

Reply to this Message

how much can a native compiler improve the performance of a java application?

Free Magazines