Re: [Fwd: Re: Xml-commons]
Iain Shigeoka <[email protected]>
| Newsgroups | gmane.text.xml.xmlpull.devel |
|---|---|
| Message-ID | <B97FE4C4.9C74%[email protected]> |
On 8/14/02 10:12 AM, "Aleksander Slominski" <[email protected]> wrote: >> I really like the pull parser interface so far. I have no real input yet >> other than it seems to work well. I would very much like to see lightweight >> DOM and XPATH support as both would be invaluable for my code. I have a >> hacked up DOM like object that I had to put together to store the document >> and sub-document data. However, I'd love to ditch it in favor of an >> actual, engineered DOM tree. :) > > i am working (slowly) on converting old XPP2 XmlPullNode to use XmlPull API > and then use it as document object model for JAXEN to support XPATH query. > the idea is to build only as much of node tree as is needed to answer query. That would be very cool. >> I also don't know if this is a common thing but I personally need XPP to be >> able to handle a lot of parallel parsed documents. Basically I'm reading in >> streaming XML from sockets for the Jabber protocol (www.jabber.org) and >> there is the potential for thousands of persistent connections each with a >> streaming XML document being parsed. Things like document tag names and >> some attributes will be repeated many times both in each stream, and between >> streams. So if there could be an option or a hook so that we can pool >> strings from the documents it would help immensely both in string object >> creation/collection and memory footprint. > > if you use default implementation of XmlPullParser in MXP1/XPP3 > (class org.xmlpull.mxp1.MXParserCachingStrings) then parser instance > will pool all identifiers (tag names, namespaces and attribute names). > parser implementation (MXParserCachingStrings) is using fast internal > cache that translates char[] to interned Strings (it uses String.intern() > and internal cache table to minimize calls to Stirng.intern()) > > please take a look on it and let me know if you would like to have > more aggressive caching. That's excellent. The only additional thing that would be handy would be the ability to cache the strings across all instances (a per-class cache). I'll have thousands of instances of the parser at any one time, and they'll all be parsing essentially the same document: <stream> <message><body>hello</body></message> <message><body>how are you</body></message> ... I know this is an extreme and probably outlying need for an XML parser so I'm not sure if its worth doing in the core distribution or if I should just develop patches to do this outside of the normal distribution. I would assume the normal use case only has one or two parser instances at any one time. Lightweight parser instances and maximum caching across all instances seems pretty unique to XML servers... I guess that may not be that rare after all though. XML servers ala web services is something people are starting to do in Java. Thanks -iain BTW - I am using MXP1/XPP3.