Yes it does use byte[] comparisons in a for loop. Let me give you a push in my direction. We know there is a performance drop in 2.4.4 that has yet to be resolved, but profiling shows it is related to interaction with the entity cache and that the CacheKey ctor ends up being the largest hotspot. By simply changing the CacheKey to use the input id directly rather than MarshalledObject, the timing of the bank unit test goes from:
2 minutes 43 seconds to: 1 minute 46 seconds Pretty big improvement for a trival change. That's the 80/20 rule in action big time. ----- Original Message ----- From: "marc fleury" <[EMAIL PROTECTED]> To: "marc fleury" <[EMAIL PROTECTED]>; "Scott M Stark" <[EMAIL PROTECTED]>; "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 5:24 PM Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > rereading the equals implementation, > > It compares the equals of a marshalled object and I am left wondering how > fast that really is. > > I guess it is a byte[] comparison under it? I don't know. > > marcf > > |-----Original Message----- > |From: marc fleury [mailto:[EMAIL PROTECTED]] > |Sent: Tuesday, November 13, 2001 8:17 PM > |To: Scott M Stark; Jboss-Development@Lists. Sourceforge. Net > |Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > | > | > ||How can it be lightweight when it has to make a deep copy of the true key > ||using serialization? Bill's change was to add yet another copy, so > | > |because the precalculated stuff is used in the subsequent calls. > | > ||now there > ||is the copying of the true key into a MarshalledObject followed by > ||a copy of > ||this > ||using MarshalledObject.get(). Your change just removed both of these which > ||seems > ||like NullPointerException territory in the equals() method. > | > |Yes the mo should be there I will add this. > | > ||Your comment in equals about the fool-proofness of this implementation > ||has already been demonstrated to be false, so unless we go beyond this > ||how is this class gaining us any performance? > | > |Because they are different issues. > | > |marcf > | > || > ||----- Original Message ----- > ||From: "marc fleury" <[EMAIL PROTECTED]> > ||To: "Scott M Stark" <[EMAIL PROTECTED]>; > ||"Jboss-Development@Lists. Sourceforge. Net" > ||<[EMAIL PROTECTED]> > ||Sent: Tuesday, November 13, 2001 3:59 PM > ||Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > || > || > ||> The basic cachekey is not expensive, in fact it is more > ||lightweight than a > ||> regular key, creating the serialized representation is expensive, and > ||again > ||> afair it was bill correcting the copy problem on key reuse > |inside one VM. > ||> > ||> marcf > ||> > || > || > || > ||_______________________________________________ > ||Jboss-development mailing list > ||[EMAIL PROTECTED] > ||https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
