I'm thinking that the user should not see anything different on their side of things. For our tests, we have made no changes to the ECperf test code. I hope we've been careful enough so as not to impact the specs and the user aspects.
However, the JBoss engine implements its internal findEntities and findCMPFields using a Collection return and then works with the Collection through Iterator. I suppose we just posed the question "What would happen if we used the underlying properties of the datastructure?" for all the changes we implemented. Our aim was not to rewrite reams of operational code and thereby change any decision logic. We approached the metadata changes in the same manner. The same applies to the use of the Trove collections. In fact, we have found that blind substitution of the Trove collections can impact performance negatively. For example, THashMap is slower for retrievals but faster for add and delete so if you are using the map for lots of reads, you lose out. Similarly, the TLinkedList is much slower when trying to iterate over it. I hope that gives some indication of our aims of exploring the data structure boundaries. We'll get you and Scott a transcript of our shorthand lab notes. Regards, JonB > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke > Sent: Saturday, 12 July 2003 2:50 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [JBoss-user] Finder performance > > > Another thing, do you require the user to do > > ArrayList list results = (ArrayList)home.findByBlah(); > > ?? > > Or are you saying the the Iterator uses get? > > Thanks, > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Jon Barnett > > Sent: Friday, July 11, 2003 11:05 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-user] Finder performance > > > > > > OK. This is just an update on the performance modifications. The latest > > change is actually not a big one - as with most of the changes I have > > implemented. > > > > The underlying findEntities works with an ArrayList but returns a > > Collection. So I changed this to return an ArrayList. The Trove > benchmarks > > show that for the same ArrayList, using a Collection Iterator over the > > native get(i) on a JVM 1.4.x gets you a penalty of between 2.2 and 2.75 > > increase in time. On Linux, the Sun JDK gives you 2.2 penalty but is > > already twice as slow as the IBM SDK. > > > > Sun > > compares ArrayList get() against Collection hasNext()/next() over 100000 > > map keys > > Iterations: 10 > > Their total (msec): 248 > > Our total (msec): 110 > > Their average (msec): 24 > > Our average (msec): 11 > > > > IBM > > compares ArrayList get() against Collection hasNext()/next() over 100000 > > map keys > > Iterations: 10 > > Their total (msec): 116 > > Our total (msec): 47 > > Their average (msec): 11 > > Our average (msec): 4 > > > > So for a heavily reliant entity bean implementation, you would > hope for an > > improvement. > > > > Using ECperf 1.1, we found that the response time averages for > operations > > dropped by between 30 and 50 percent. > > > > Hope that is useful. > > > > JonB > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Parasoft > Error proof Web apps, automate testing & more. > Download & eval WebKing and get a free book. > www.parasoft.com/bulletproofapps1 > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user
smime.p7s
Description: S/MIME cryptographic signature
