[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