do you have any numbers on this ? E.g. Sun's collection classes against Trove ?
Performance is a moving target; ie. in one release of the VM, object creation kills you, and in the next it is gone (JDK 1.4). Or try-catch is bad, then in 1.4. the overhead is gone too.
Question is: should we bank on Trove for keeping up-to-date with a moving target (moved by Sun), or should we trust Sun to do the right job ?
But anyways, your measurements are very useful, and I would be interested in seeing all numbers.
I'm thinking of moving all my custom built data structures over to JDK collections, in support of my previous argument. But of course I'd reconsider if you can show mediocre performance in the native coll classes.
Regards,
Jon Barnett wrote:
Good question. I'm not saying that standard JBoss should include them. I'm just investigating the impact.
Now the GNU projects have always been high quality, and the Trove package seems to have reached a certain level of maturity so I feel that I can play with the intermix just to see what happens. I'm also getting deep into the JBoss code just to understand the structure so that can only be good.
I can't definitely say that this will lead to anything - the interactions are so complex with J2EE systems that things may cancel themselves out. But you won't know until you try and without measurements things are more speculation than certainty. I have stabilised some of the memory usage I think, in 3.2.0 with the metadata processing by making internal use of the existing ArrayLists and trimToSize() - performance and memory consumption seems less spikey (without resorting to the Trove classes). Haven't done a thorough test as yet.
The Sun implementations are safe, but without healthy competition, they probably wouldn't push the boundaries. The memory usage and speed in their collections are not optimal and without a comparison implementation it's hard to say how good the Sun release will be. And from testing, their JDK performance in most respects seems below par compared with other vendors. All I'm doing is testing the boundaries with JBoss - it's fast, but I'm just curious at how fast it can go, how smooth the delivery is and what might hold it back.
I've done a quick test under Windows and the Sun JDK (a run of 3000 samples) - the changes so far including some Trove insertions (again only in parts of the server branch of code) have dropped the steady state average response times from 44 ms to 36 ms and the JMeter graphs show a nearly continuous line at 20 ms with upward deviations dragging the average up. That is an improvement of 15% ~ 18% and with only a couple of days tinkering.
What does it mean? I'm not sure - do we want faster JVMs? Are we happy with choppy response? Are there problems in the code? Is it a problem with the JVM? Brighter minds must think on this. I'm only making observations. ;)
JonB
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bela Ban Sent: Tuesday, 1 July 2003 2:48 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] On the performance trail - again
Hi Jon,
I haven't played with Trove yet, so bear with me.
My question is, is it wise to use the Trove collection classes when you have them in the JDK already ? Also, in Tiger (JDK 1.5) we will have collection classes that are further optimized and suited for high-performance reentrant use (java.util.concurrent). Essentially Doug Lea's concurrent.util as native JDK.
Bela
-- Bela Ban http://www.javagroups.com Cell: (408) 316-4459
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
