Antoine Pitrou <pitrou@free.fr> added the comment:
My point is that if you say thing like "significantly/several times higher memory footprint than X" you are basically scaring the users away from the module.
Only those users who know they'll be processing significantly large documents. I don't think "scaring away people" is a good enough reason *not* to document performance characteristics. For example, we already mention that string joining is faster than repeated concatenation; I haven't heard anyone complain that it scared people away from string concatenation. And while it's true that we shouldn't try to document performance characteristics *too precisely*, it is still a good thing to document the most outstanding facts (for examples, C accelerator modules are clearly superior in performance to pure Python modules; should we shy away from documenting that, and instead present it as some kind of neutral choice?). And, of course, if minidom gets some serious performance attention, the claims will have to be revisited. But given the amount of attention minidom gets at all, it sounds rather implausible.
If for an average documents it takes, say, 30-50MB of memory, it seems perfectly reasonable to me, even if ElementTree takes 3-5MB. I would actually consider 100-200MB still ok too
Some use cases would not really like a 100-200MB memory consumption, or even 50MB. Think a long-running daemon, for instance. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue11379> _______________________________________