OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: String interning (WAS: SAX2/Java: Towards a final form)

[ Lists Home | Date Index | Thread Index ]
  • From: Miles Sabin <msabin@cromwellmedia.co.uk>
  • To: David Megginson <david@megginson.com>
  • Date: Fri, 14 Jan 2000 19:33:10 -0000

David Megginson wrote,
> I was very concerned about this use case at first, but my 
> concerns lessened a bit once I started to consider 
> implementation details.
>
> If I'm writing a filter, where do the strings for the names 
> I'm passing on come from?

I'd put filters in a slightly different box. Layers of SAX
handlers feeding into XMLReaders feeding into handlers ...
will come out fine, because, as you say, everything is
String.intern()'d from source to sink.

> Iterating over a DOM, on the other hand, is a legitimate 
> problem. Every DOM implementation worth its salt will have 
> interned all element and attribute names (a DOM tree is big 
> enough already), but there's no way to be sure of that in the 
> general case, or to be sure that the names are == the results 
> of java.lang.String.intern().  

Not just a DOM. Quite a few people are sitting SAX on top of
all sorts of data-structures which don't necessarily make any
interning guarantees. And don't forget database queries.

> Too bad the DOM level one Java binding didn't require that.

Hmm ... similar issues. Some people layer DOM implementations
on top of non-DOM data structures, java-reflection and DB
queries.

> > The other scenario is mine (multiple parsers running over
> > arbitrary documents in multiple threads) where the global
> > String.intern() map is a point of contention. I won't bore
> > everyone with the details again.
>
> I'm much more skeptical about this one, because there are so 
> many preconditions:
>
> [snip: 4 conditions]
>
> If all of these conditions arise at the same time (and I 
> question #3 and #4), then perhaps over-all XML parsing might 
> slow down by 1-2%; if the actual XML parsing represents even 
> as much as 30% of the processing time (the rest is taken by 
> whatever the ContentHandler callbacks do with the 
> information), that's a 0.6% slowdown under these
> circumstances.

Those four conditions cover my situation pretty accurately.
You'll just have to swallow (3), but (4) is the single-
processor vs. multi-processor thing. 

> Granted, the potential speedup for other apps probably isn't 
> much greater, but since the vast majority of SAX apps will 
> not meet the above criteria, and since the penalty when one 
> does meet these criteria is so small, it makes sense not to 
> penalize everyone else.

OK, there's not much I can say to that. If I really am doing
something very far out then it'd be unreasonable for you to
twist the API to suit me.

I'm not convinced tho'. This isn't quite my app, but I can 
imagine people wanting serve HTML generated via XSL from 
heterogenous XML on a heavily loaded, multi-threaded HTTP server.
It'd be a shame if lock contention issues made it harder for
them to scale up to more users by sticking a couple more
processors in the box.

> If there's any real concern, I think, it's the DOM scenario.

Arkin? Comments?

> > [snip big case statement example]
> > To be honest, tho', I don't see any particular reason why 
> > the SAX API should be expected to support this sort of 
> > code.
>
> How about running in a tight loop?

I doubt that the difference between String.equals() and == would 
be critical even here if the code under the conditionals does
much work. But even if it _is_, adding an interning method
to XMLReader,

  String intern(String toBeInterned);

would do the trick,

  // In startDocument() or outside the ContentHandler
  // altogether

  RDF = r.intern("http://www.w3.org/1999/02/22-rdf-syntax-ns#");
  ABOUT = r.intern("about");
  ID = r.intern("ID");
  ABOUT_EACH = r.intern("aboutEach");

  XHTML = r.intern("http://www.w3.org/1999/xhtml");
  HREF = r.intern("href");
  CLASS = r.intern("class");
  NAME = r.intern("name");


  // In startElement()

  for (int i = 0; i < len; i++) {
    String name = atts.getName(i);
    if (atts.getURI(i) == RDF) {
      if (name == ABOUT) {
        do something
      } else if (name == ID) {
        do something
      } else if (name == ABOUT_EACH) {
        do something
      }
    } else if (atts.getURI(i) == XHTML) {
      if (name == HREF) {
        do something
      } else if (name == CLASS) {
        do something
      } else if (name == NAME) {
        do something
      }
    }
  }

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS