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?
>
>

Reply via email to