Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] QName flyweights

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Mik Lernout <mik AT futurestreet.org>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] QName flyweights
  • Date: Fri, 10 Jun 2005 09:10:41 -0700

My 2 cents: I work a lot in multi-threaded, heavy-usage environments,

Me too!

However, I expect the synchronization overhead to be mostly negligible even in these environments: The synchronization is rather short-lived: localized to map.get() and map.put(). These operations are very fast, in particular considering that the name and URI involved in QName.hashCode() and QName.equals() are typically (but not necessarily) String constants, often reducing equality to == and hashCode to the String.hashCode cache lookup, both O(1).

In extreme cases where lock contention might indeed become a problem one could eliminate all synchronization by putting the cache map into a ThreadLocal. But I would recommend not doing that by default. Let's first see how the simple approach works...

On Jun 9, 2005, at 10:46 PM, Mik Lernout wrote:

My 2 cents: I work a lot in multi-threaded, heavy-usage environments, and those synchronized blocks are way to wide and will crush performance when running in ore than one thread. Elliotte: can you add concurrent access in your test cases.

You just need a weak referenced Map as a cache, and use "double checking", or not, as I don't think it is that dangerous that there are two equal QNames floating around of which only one is saved in the cache...

I'm not sure I understand what you mean with "double checking" and why weak references would be significantly benefitial.

Wolfgang.




Archive powered by MHonArc 2.6.24.

Top of Page