From: Bill B. <bi...@jb...> - 2003-06-30 19:29:43
|
KEEP UP THE GOOD WORK! This is very useful stuff and I'm very curious what happens as a result with your experiments with Trove. Although, I think more bang will come out of: 1. Reducing the number of global synchronizations. i.e. A static variable that is being synchronized by everybody. 2. Reducing memory allocations all over. And no, pooling of objects should not be done. Some of the research out there states that pooling is no more performant than straight allocations. Plus, I don't want the code getting dirty with pooling code. Bill > -----Original Message----- > From: jbo...@li... > [mailto:jbo...@li...]On Behalf Of Jon Barnett > Sent: Monday, June 30, 2003 2:11 PM > To: jbo...@li... > Subject: RE: [JBoss-user] On the performance trail - again > > > 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: jbo...@li... > > [mailto:jbo...@li...]On Behalf Of Bela Ban > > Sent: Tuesday, 1 July 2003 2:48 AM > > To: jbo...@li... > > 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 > |