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 |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, November 13, 2001 6:51 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed | | |It wasn't Bill that added this. It was first added in 1.2 and then expanded |in |1.8, more copying added in 1.10, etc. This whole thing started to create an |idiot proof key, which cannot be done. Instead we have a big fat expensive |key that is killing performance. Let the user live and die by their ability |to |code an entity key class. | |xxxxxxxxxxxxxxxxxxxxxxxx |Scott Stark |Chief Technology Officer |JBoss Group, LLC |xxxxxxxxxxxxxxxxxxxxxxxx |----- Original Message ----- |From: "marc fleury" <[EMAIL PROTECTED]> |To: "Jboss-Development@Lists. Sourceforge. Net" |<[EMAIL PROTECTED]> |Sent: Tuesday, November 13, 2001 3:11 PM |Subject: [JBoss-dev] CacheKey copy semantics and speed | | |> I am reading the CMR 2.0 code and I see that it makes intensive |use of the |> CacheKey creation (which I guess is normal). |> |> In cachekey, the change introduced by Bill, i.e. to enforce copy |semantics |> is a very slow operation. It involves a full serialization. This has |> negative effects. |> |> 1- it slows the finders |> 2- it slows the cmr stuff |> 3- thank god it doesn't affect the "normal operation" speed which is the |> optimized lookup |> |> One of the points of the cachekey is to be fast, uber fast by |precompiling |> the key hashcode to be used and the equals. I understand the |problem that |> bill was trying to solve with the serialization but it is just too |> expensive. |> |> I want to turn this behavior off by default, Bill if you feel strongly we |> could put an optional field so that these keys are copied but by default |it |> is a killer. |> |> It must be a property of the cache and I intend to expose more of them |> through the JMX interface. In any case it would be a jboss.xml thingy. |> |> Just being a good boy and following Scott's demand for |"tracking" changes, |I |> fully agree. |> |> marcf |> |> |> |> xxxxxxxxxxxxxxxx |> Marc Fleury |> President |> JBoss Group, LLC |> xxxxxxxxxxxxxxxx |> |> |> _______________________________________________ |> 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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
