[jbosscache-dev] Fqns and immutability

Brian Stansberry brian.stansberry at redhat.com
Fri Mar 2 08:37:12 EST 2007


I'm a bit doubtful that a map lookup would be faster than constructing a 
new Fqn.

The weak map could be tricky too. I guess you'd have to write your own 
that would use Arrays.equals() in the lookup rather than 
Object[].equals(Object[]). I believe the latter comes down to Object[] 
== Object[], which would likely fail.

Still, 6% is a lot!

Manik Surtani wrote:
> Related to the "Fqns-as-strings" discussion, we assume that all Fqns are 
> immutable.  I.e., they have no mutators and when we peek() at their 
> elements, we get an immutable collection.
> 
> But this does not mean that Fqns which are equal point to the same 
> object though.  For example,
> 
>     assertSame(Fqn.fromString("/stuff"), Fqn.fromString("/stuff"))
> 
> fails even though
> 
>     assertEquals(Fqn.fromString("/stuff"), Fqn.fromString("/stuff"))
> 
> passes.
> 
> The question to ask is, should the Fqn constructors be made private (or 
> protected), forcing users to use factory methods like 
> Fqn.fromString(String s) and Fqn.fromObjects(Object... objects) and 
> Fqn.fromObjects(Fqn base, Object... objects) so that these factory 
> methods can maintain references to existing Fqns (perhaps in a weak map 
> so they can be gc'd when no longer referenced) and reuse these if 
> possible rather than construction all the time?
> 
> This was prompted by my running some profiling tests on 2.0.0.BETA1 and 
> found that almost 6% of the time spent (only on a particular test - so 
> not a generic comment) was spent on Fqn construction.  And quite often 
> this was the same Fqn.
> 
> Thoughts?
> -- 
> Manik Surtani
> 
> Lead, JBoss Cache
> JBoss, a division of Red Hat
> 
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com




More information about the jbosscache-dev mailing list