well, then you don't win,
but I don't win either today is a crappy day but the fix is relevant marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, November 13, 2001 8:55 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed | | |Ok, but all of that time was really due to the removal of the |MarshalledObject.get(). Running with the CacheKey implementation |pre the copy gives basically the same time as the non-MarshalledObject |version: | |1 minute 48 seconds | |----- Original Message ----- |From: "Scott M Stark" <[EMAIL PROTECTED]> |To: "Jboss-Development@Lists. Sourceforge. Net" |<[EMAIL PROTECTED]> |Sent: Tuesday, November 13, 2001 5:43 PM |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed | | |> |> 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. |> | | | |_______________________________________________ |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
