[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: org.xml.sax.AttributeMap
>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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|