> > - lowering the huge (re)allocation sizes in the DOM heap in > > DOMDocumentImpl.cpp or (obviously a better idea) porting the new > > APIs that were added to 3.0 to control the size from the application > > I think it should be straightforward to port this to 2.8.0 without > breaking the interface compatibility. Would you like to prepare and > test a patch for the xerces-2.7 branch?
I can certainly do that. Are there specific tests that ought to be run apart from any of mine? > As a side note: this method does not seem to work for DOM documents > that are parsed from XML instead of created by the application (that > is, the document created by a parser will use the default allocation > size during parsing). Any thoughts on that? I was just reviewing it now (I hadn't actually looked at it before because I knew 3.0 was a ways off) and I came to the same conclusion. I was assuming he had added a new API to control the size constants globally, rather than as part of the DOMMemoryManager class. For my purposes this is ok because he also reset the initial block size to 8k, which is what I use, and then he grows it dynamically. Perhaps this is an acceptable compromise (it's ideal for me since I wouldn't need to call the new API at all), but I think people with large document workloads would need to test it to determine if it impacts their performance. I don't have anything like that I could test. I think we could combine this patch with a second patch to DOMMemoryManager to control the block size values if people prefer that. I can prepare a patch with either approach... BTW, I'm also willing to help with any release tasks. Thanks, -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
