Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java performance

Reply
Thread Tools

Java performance

 
 
Christian
Guest
Posts: n/a
 
      11-04-2007
Joshua Cranmer schrieb:
> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>> I am just interested in the latest stats on Java performance. A lot
>> of the literature appears to be out of date in this respect. Is it
>> true that Java performance is close to that of native compiled code?
>> I suppose it could be said that Java *is* natively compiled (at run
>> time), but there will surely be performance penalties due to bytecode
>> translation, at least at program startup.

>
> In the extreme short-term (i.e., in the first few minutes), Java is
> going to have noticeable impact: one comparison metric gives it about
> 1.2-1.3 times native code (after taking startup into account). Over
> longer periods of time--especially if the server VM is used--Java
> performance is near, at, or better than native compiled code.
>
>> Finally, I have read that garbage collection is generally more
>> efficient than manual memory management. Is this true, and if so,
>> why?

>
> In most cases, yes. Part of the problem is that manual management is
> manual and people are not quite as good at profiling memory as computers
> are. In addition, garbage collection can more easily benefit from
> parallel execution, a bonus in the coming days of multi-core CPUs and
> other parallelization techniques.
>


though there seem to be other problems with compiling in java ...
I once heard the term "hotspotless" code used for GUI parts written in
pure java..
meaning that java's guis have the problem that they are not hot spots
... as a user won't klick each button that often resulting in gui code
not being compiled down to native code but just allways being
interpreted which might result in an unreactive GUI as an effect (or at
least a GUI that is less reactive than a native couterpart)
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      11-04-2007
On Sun, 04 Nov 2007 19:16:25 GMT, Joshua Cranmer
<(E-Mail Removed)> wrote, quoted or indirectly quoted someone
who said :

>In the extreme short-term (i.e., in the first few minutes), Java is
>going to have noticeable impact: one comparison metric gives it about
>1.2-1.3 times native code (after taking startup into account). Over
>longer periods of time--especially if the server VM is used--Java
>performance is near, at, or better than native compiled code.


On an older machine you will notice a difference the Swing GUI makes.
It has an extra layer of overhead between the application and the
hardware. With a 2 GHz machine you likely won't notice it. It as fast
enough to keep up with a human.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      11-04-2007
Christian wrote:
> .. as a user won't klick each button that often resulting in gui code
> not being compiled down to native code but just allways being
> interpreted which might result in an unreactive GUI as an effect (or at
> least a GUI that is less reactive than a native couterpart)


I don't really understand the first part of your sentence, but I can
deal with the last part of it:

Unresponsive GUIs are more a symptom of poor programming skills (e.g.,
someone's doing too much in the EDT that could be done elsewhere) than
of native-versus-non-native code problems. I have seen native GUIs
become unresponsive just as much--in both Windows and Linux implementations.

In fact, from the little I know of various toolkit implementations, this
is just as much a problem in Java Swing code as it is GTK2 or Windows API.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-04-2007
On Sun, 04 Nov 2007 20:32:21 +0100, Christian <(E-Mail Removed)> wrote,
quoted or indirectly quoted someone who said :

>though there seem to be other problems with compiling in java ...
>I once heard the term "hotspotless" code used for GUI parts written in
>pure java..
>meaning that java's guis have the problem that they are not hot spots
>.. as a user won't klick each button that often resulting in gui code
>not being compiled down to native code but just allways being
>interpreted which might result in an unreactive GUI as an effect (or at
>least a GUI that is less reactive than a native couterpart)


The whole point of hotspot is you don't waste the RAM for native code
or the CPU time to optimally compile unless the method is frequently
used.

Sun people are primarily thinking today about server code that runs
for days at time. What counts is how well it performs after the first
5 minutes of running.

The big desktop or Applet performance hit today is the time it takes
to load the Java run time and hotspot hundreds of standard classes. I
have suggested ever since I first encountered Java they could greatly
speed up launch by precompiling a set of commonly used classes and
capturing the RAM image with a process I call gespenstering I used in
DOS Abundance to create relocatables out of raw RAM images.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Sherman Pendley
Guest
Posts: n/a
 
      11-04-2007
(E-Mail Removed) writes:

> I am just interested in the latest stats on Java performance. A lot
> of the literature appears to be out of date in this respect. Is it
> true that Java performance is close to that of native compiled code?


True in many cases, yes.

> I suppose it could be said that Java *is* natively compiled (at run
> time), but there will surely be performance penalties due to bytecode
> translation, at least at program startup.


That's one reason that Java is currently far more popular for long-running
server applications than it is for browser applets or desktop apps. Startup
time isn't such a big deal when the app is rarely killed and restarted.

> Can Java be used for graphics-intensive applications, such as the
> latest 3D game, such as Doom/Quake/whatever is the current hot game.
> If not, what are the issues that prohibit Java from being suitable.


I've quite a bit of experience in cross-language development (see my .sig),
and in my experience the cost of crossing the language barrier tends to be
pretty high. That doesn't make Java unsuitable for high-performance 3D apps,
it just means you need to carefully think about and manage how your Java
code calls the low-level 3D rendering functions.

> Finally, I have read that garbage collection is generally more
> efficient than manual memory management. Is this true, and if so,
> why?


It's easier than some manual schemes, and about on par with others. It's
definitely easier than old-school malloc()/free(). But, there are "semi-
manual" techniques such as those used in C++ (stack-based objects and STL
collections) or Objective-C (autorelease pools and design patterns that
support them) that are also much easier than the old-school approach.

Sun likes to pretend that the old-school approach is the only possible
alternative to Java, so as to make Java look better in comparison. The
truth isn't as black-and-white as that.

sherm--

--
WV News, Blogging, and Discussion: http://wv-www.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
 
Reply With Quote
 
=?ISO-8859-1?Q?Arne_Vajh=F8j?=
Guest
Posts: n/a
 
      11-05-2007
Christian wrote:
> I once heard the term "hotspotless" code used for GUI parts written in
> pure java..
> meaning that java's guis have the problem that they are not hot spots
> .. as a user won't klick each button that often resulting in gui code
> not being compiled down to native code but just allways being
> interpreted which might result in an unreactive GUI as an effect (or at
> least a GUI that is less reactive than a native couterpart)


I find it hard to believe that the effect of like 20 statements
in an actionPerformed being JIT'ed or not should be noticeable.

A difference between 1 micro second and 20 microseconds is
relative big. But a GUI user needs damn sharp eyes to notice
the difference.

Arne
 
Reply With Quote
 
Knute Johnson
Guest
Posts: n/a
 
      11-05-2007
Lew wrote:
> Knute Johnson wrote:
>> The coming JRE is going to have greatly improved startup performance.
>>
>> https://jdk6.dev.java.net/6uNea.html
>>
>> I've played with it a little bit on windows and there does seem to be
>> some performance increase.

>
> If you really are talking about Java 6, it's been out already for almost
> a year.
>


Read the article.

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-05-2007
On Sun, 04 Nov 2007 09:21:55 -0800, Knute Johnson
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>The coming JRE is going to have greatly improved startup performance.
>
>https://jdk6.dev.java.net/6uNea.html


"The Quick Starter feature will prefetch portions of the JRE into
memory, substantially decreasing the average JRE cold start-up time
(the time that it takes to launch a Java application for the first
time after a fresh reboot of a PC)."

Sounds like they are loading a pre-loaded RAM image to get the basic
classes going. Yea! I have been asking for this since day 1.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
borophyll@gmail.com
Guest
Posts: n/a
 
      11-05-2007
On Nov 4, 9:41 pm, (E-Mail Removed) wrote:
> I am just interested in the latest stats on Java performance. A lot
> of the literature appears to be out of date in this respect. Is it
> true that Java performance is close to that of native compiled code?
> I suppose it could be said that Java *is* natively compiled (at run
> time), but there will surely be performance penalties due to bytecode
> translation, at least at program startup.
>
> Can Java be used for graphics-intensive applications, such as the
> latest 3D game, such as Doom/Quake/whatever is the current hot game.
> If not, what are the issues that prohibit Java from being suitable.
>
> Finally, I have read that garbage collection is generally more
> efficient than manual memory management. Is this true, and if so,
> why?
>
> Please feel free to mention anything else that is relevant...
>
> Regards,
> B.


Thanks all for the responses. The feeling I am getting is that Java
is not very suitable for apps where it needs to interact quite closely
with the machine (such as graphics, device I/O) because of large
runtime overhead of JNI. Can this overhead be circumvented by
compiling Java to native code? Or is it unavoidable for some reason..

Does Java suffer from GC pauses anymore(on UP systems), or are they a
thing of the past?

<OT> I am looking for a language that is as close to the metal as C++,
yet has garbage collection, which I think is a better idea than manual
mm. Any ideas? </OT>

 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      11-05-2007
Roedy Green <(E-Mail Removed)> writes:

> On Sun, 04 Nov 2007 09:21:55 -0800, Knute Johnson
> <(E-Mail Removed)> wrote, quoted or indirectly quoted
> someone who said :
>
>>The coming JRE is going to have greatly improved startup performance.
>>
>>https://jdk6.dev.java.net/6uNea.html

>
> "The Quick Starter feature will prefetch portions of the JRE into
> memory, substantially decreasing the average JRE cold start-up time
> (the time that it takes to launch a Java application for the first
> time after a fresh reboot of a PC)."
>
> Sounds like they are loading a pre-loaded RAM image to get the basic
> classes going. Yea! I have been asking for this since day 1.


That, or they are making yet another "QuickStart" that loads and takes
up memory at boot time, whether you use it or not.
It can sit next to Office QuickStart, Firefox Quickstart and
a gazillion other programs that think they are so important that
you have to start everything but the GUI every time you start
your machine.

/L
--
Lasse Reichstein Nielsen - (E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Performance Tutorials Services - Boosting Performance by DisablingUnnecessary Services on Windows XP Home Edition Software Engineer Javascript 0 06-10-2011 02:18 AM
Web Form Performance Versus Single File Performance jm ASP .Net 1 12-12-2003 11:14 PM
Java performance hints and tips? Ahmed Moustafa Java 9 07-16-2003 03:16 AM
Weak Java performance with Sony Ericsson T610? totojepast Java 0 07-10-2003 03:52 PM



Advertisments