Andy Clark wrote: > So I'm thinking of adding a feature to Xerces2 that > allows applications to set whether the scanner re- > uses its character buffers. If the scanner doesn't > reuse buffers, then my converter doesn't have to > copy anything. Therefore, the performance of the > pull-parser driven by Xerces2 should be better.
hi, that would be great- i have hit this problem when implementing XMLPULL API on top of Xerces 2 XNI. another great feature would be ability to "lock" parser buffer content so when i receive multiple character() call-backs i know that XMLString offset and length will be valid as parser will just create bigger buffer to keep larger content. then later i unlock allowing parser to reuse current buffer (so parser can start writing to buffer from beginning). it would be interesting to compare if such reuse of growable buffer is more efficient then fixed buffer (AFAIK it is current implementation in Xerces) and the option you describe when scanner never reuses the buffer - how does it sound? > Of course, you could always write an implementation > only for the pull-parsing API that wouldn't suffer > this problem at all. You could even drive the API > from other pull-parsing APIs like XPP, etc. :) that is where good layering becomes important for good performance (lower level must be efficient :-)) and i think about XML pull parsing as being quite low level and very efficient (similarly to SAX), natural layer just above XML tokenizer that can be used to build higher levels efficiently (like increment xml node trees). thanks, alek --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
