Skip to main content

Performance problems when upgrading from JDK1.4.2 to 1.5.0

11 replies [Last post]
oda66
Offline
Joined: 2006-01-23
Points: 0

Hello,

we have some performance problems after an upgrade from JDK 1.4.2 to 1.5.0 in a fairly large web application running under Windows and Linux with Apache Tomcat/4.1.30. A test process which mainly carries out a extraction/conversion of data (a lot of file I/O operations) slows down by a factor of about 2.

In a first approach to reach at least the 1.4.2 performance, we tried several JVM options and different combinations of them (such as -Xms, -Xmx, -Xincgc, -Xconcurrentio, -XX:MaxGCPauseMillis, -XX:GCTimeRatio) as well as a forced garbage collection (System.gc()) from time to time. We did not see significant changes when changing the VM options. On the other hand, the forced garbage collection needs less time with 1.5.0.

Thanks in advance for any helpful ideas.

Olaf

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tchang99
Offline
Joined: 2006-11-29
Points: 0

We've experienced a similar problem when upgrading from jdk 1.4.2 to 1.5.0. our profiling has revealed that the after(...), before(...), and equals(...) methods in the calendar class are taking significantly longer to execute. has sun produced a fix for this? i searched their bugs database and nothing came up.

ted

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

well, then way don't file a bug-report?

lg Clemens

tvaananen
Offline
Joined: 2003-12-01
Points: 0

I have also notice the toString() problem. It can really have destructive implications to your application. This is truely a sad thing because the problem pops up with classes like StringBuffer, which is widely used with toString().

mgrev
Offline
Joined: 2003-08-12
Points: 0

GregorianCalendar is a real performance hog, as well as a memory hog. Use it only when absolutely needed and use a substitute class that holds the necessary information with an optinal reference to a created GregorianCalendar when needed. Since .after(), .equals() and .before() are really fast operations you can do those on a long (timeInMillis()) instead, minding the locale and time zone for equals of course.

We have done this in MiG Calendar and the speedup was VERY noticable (both for 1.4 and 1.5) when using a lot of activities (which has a start and end date).

Cheers,
Mikael Grev

teilo
Offline
Joined: 2004-02-02
Points: 0

Do you make use of StringBuffers internally and call toString() on them?

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6219959

oda66
Offline
Joined: 2006-01-23
Points: 0

> Do you make use of StringBuffers internally and call
> toString() on them?
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=621
> 9959

Thanks for your suggestions! We now made a detailed performance comparison with JProbe. In fact, we have calls of toString() in the program, and these calls need about 3-4 times more time for JDK 1.5.0. However, their total contribution is only about 1% of the program runtime. What turned out to be the real problem is the extensive use of the class GregorianCalendar with its methods "before", "equals", and "after". They are about 100 times slower for JDK 1.5.0, which leads to a contribution of about 50% of program runtime and completely explains our loss of performance.
We reported this problem to Sun Developer Network, it is in progress there.

scolebourne
Offline
Joined: 2003-06-20
Points: 0

You could try switching to Joda-Time - http://joda-time.sourceforge.net. I think you'll find it an all round better experience than JDK Calendar.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

Could you please post a bug-report at http://bugs.sun.com together with a small example-code which shows the problem.

It should take only 10 minutes but this way you could help Sun keeping performance of java high.

lg Clemens

olsonje
Offline
Joined: 2005-08-10
Points: 0

Have you tried using tomcat5.5 instead of 4.1? There are changes you have to make to the context layout, but at least you'd be using something to take advantage of 1.5 instead of using a tomcat4.1 setup?

oda66
Offline
Joined: 2006-01-23
Points: 0

> Have you tried using tomcat5.5 instead of 4.1? There
> are changes you have to make to the context layout,
> but at least you'd be using something to take
> advantage of 1.5 instead of using a tomcat4.1 setup?

We plan to do so some time, but the present problem should definitely not be the tomcat version. The test case we ran is a simple job of the form
java

which even runs without a tomcat being started... Any other ideas?

olsonje
Offline
Joined: 2005-08-10
Points: 0

@oda66:
Maybe explain more of what your test are so we can see what your doing that might have caused issues? I mean I am no performance guru or anything, but I'll see if I can help at all.