Lists Home |
Date Index |
- From: "Don Park" <firstname.lastname@example.org>
- To: "Antony Blakey" <email@example.com>, "xml-dev Mailing List" <firstname.lastname@example.org>
- Date: Tue, 24 Feb 1998 23:16:21 -0800
>Why would you not simply return a strongly typed data item (ignoring the
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
>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
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.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)