Hi, We disable this feature in our app despite the fact that the documents can be huge (tens of MBs or more), because the app always needs to access all nodes, sooner or later, so there's no reason to defer their expansion.
BTW, I think I've encountered some problems with deferred nodes in the past. Some XPath engines might have not worked well with them. I was surprised by that, because I thought that node expansion deferral ought to be transparent to the user, but it wasn't. Alex > -----Original Message----- > From: Dennis Sosnoski [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 20, 2002 11:31 AM > To: [EMAIL PROTECTED] > Subject: Re: Defer node expansion > > > As far as I've seen this is correct - deferred node expansion is only > useful on fairly large (perhaps 20KB+) documents. I've commented before > that I really don't think it's good to have this enabled by default, > since it dramatically increases the memory usage for small documents and > also slows processing. On large documents, it reduces the memory usage > and improves speed by perhaps 10-30%. *Given the tradeoffs it seems like > it should default to "off" with a FAQ mention that turning it on may > improve large document performance.* > > I assume the increased memory usage for small documents is due to > structures set up to handle the deferred node data, but haven't > investigated the code to find out details. > > BTW, I have run tests more recently than those published on my web site > (from February of this year). I'll be including some results by way of > comparison in a data binding article coming out next month. I haven't > noticed any substantial changes to Xerces2 performance since the results > on the web site were published, though. > > - Dennis > > Dennis M. Sosnoski > Enterprise Java, XML, and Web Services Support > http://www.sosnoski.com > > [EMAIL PROTECTED] wrote: > > >Performance tests (and our experiences) were showing that enabling defer > >node expansion degrades performance on small documents even if processing > >only part of them. This was a few months back...have recent improvements > >changed this situation as far as anyone knows? > > > > > > > > > > > > > Joseph Kesselman > > > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > > > om> cc: > > > Subject: Re: > Defer node expansion > > 11/20/2002 09:31 > > > AM > > > Please respond to > > > xerces-j-user > > > > > > > > > > > > > > > > >On Wednesday, 11/20/2002 at 02:46 ZE2, Pavel Ausianik > ><[EMAIL PROTECTED]> wrote: > > > > > >>Could somebody explain when the defer node expansion should be used in > >>xerces 2? > >> > >> > > > >1) When you don't intend to examine the entire document, this choice can > >save memory and parsing time. > > > >2) When latency (time before you can access the first node) is more > >important than throughput (time before you can access the last > node), this > >choice can make your program more responsive. > > > >Hence, deferred node expansion tends to be particularly helpful when > >processing only part of a large document. But it may cost > performance when > >processing all of a small document. That's why it's optional. > > > > > >(Note the similarity to Xalan's "incremental DTM" mode.) > > > >______________________________________ > >Joe Kesselman / IBM Research > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
