DOMMemDebug is a class that is used by the DOM test programs to check for leaks resulting from problems with the reference counted memory management.
It's just a small amount of code, and it didn't seem worth the trouble to set up the build to omit it from the release build. Complicating the picture a bit, we do build and run the tests on the release build also, and without a DOMMemDebug implementation available, their build would fail. DOMMemDebug is not used directly from the DOM implementation, but only from the test programs. There are a number of counters within the DOM implementation that DOMMemDebug references. It might be worth omitting the code that updates these counters from the release builds, since it does run in the course of normal DOM operation, and presumably takes some amount of time. But in the performance tests that I have run, while the updating of the reference counts in the DOM is visible, the object instance counters - the ones used by DOMMemDebug - don't show up as being significant. It's not obvious to me why Purify would complain about DOMMemDebug leaking, since it allocates no storage at all. -- Andy From: "KRAUSE,MIKE (HP-FtCollins,ex1)" <[EMAIL PROTECTED]> > > When I run purify on my code, I get several memory leaks from a class called > DOMMemDebug. This resides in the xerces library. Should this really be > built into the release version of the XML parser? > >