org.xml.sax.AttributeMap

[Don Park]

>Why would you not simply return a strongly typed data item (ignoring the
>names)

Because we are trying to minimize the number of classes to the bare minimum.
I don't feel too strongly about the goal but I felt I should make a
suggestion.

>As far as reuse of values is concerned however, I think this is a very
>bad idea: startElement defines a new context, so reusing the parameters
>to that call is workable, however reusing the result from the
>getDataInfo call is a different kettle of fish. It would be better (if
>you are so concerned) to keep a pool that you return so that they are
>not reused within the context of a startElement call. This may seem like
>more work on the part of the parser implementor, but you shouldn't push
>this complexity onto the users of the parser when you can safely hide it
>within the parser. The parser writer can make the effort for
>efficiencies sake.

What I suggested is not any worse than AttributeMap being reused by some of
the parsers since the returned value's lifetime is entirely bound by
lifetime of AttributeMap.  Note that AttributeMap's Enumeration is also
invalid once startElement returns.  But then I am not at all saying that
what I suggest is good.

One of the problem facing SAX is its speed.  There are far too much objects
(mainly Strings) being instantiated unnecessarily because of multiple layers
involved.  One of the users of SAXDOM measured performance at three levels
(SAX, SAXDOM, and his own application on top of SAXDOM) and found that
performance decreased by about 50% at each level.  Processing of a 1.5 meg
XML file took 8 seconds at SAX level, 14 seconds at SAXDOM, and 35 seconds
at the application level.  I don't know which SAX parser was used.

Since I have a particular interest in server-side XML processing, I have a
real concern about performance.  I am currently feeling out the issues on
building a 'pedal-to-the-metal' XML parser with native SAX support.
Actually, I am finding that my performance goals can not be met with current
SAX API because I must cut down object instantiation down to bare minimum,
remove most synchronization, and cluster each stage to allow JIT more
effective use of CPU code cache.

Don Park
http://www.quake.net/~donpark/index.html



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)