Benefits of xml.dom.minidom?

[John Gordon]

I recently inherited some code that uses xml.dom.minidom to build a large
XML document, and I noticed that it is quite slow and uses a ton of memory.

I converted the same code to use lxml.etree and it is much faster and
uses not nearly so much memory.

Why is minidom so hungry for resources? What is it doing with all that
memory and CPU?

 

[Stefan Behnel]

John Gordon, 20.10.2011 19:46:

I recently inherited some code that uses xml.dom.minidom to build a large
XML document, and I noticed that it is quite slow and uses a ton of memory.

I converted the same code to use lxml.etree and it is much faster and
uses not nearly so much memory.

Why is minidom so hungry for resources? What is it doing with all that
memory and CPU?

Not much. It's memory hungry because it builds a tree from rather heavy XML
objects and is neither optimised for speed nor for a low memory footprint.
Its main purpose is to be (mostly) W3C DOM compatible. It's also been in
the standard library for quite a bit longer than ElementTree, and predates
lxml by years. That's the most likely reason why your original script was
written using minidom.

In a way, it's unfair to compare minidom with lxml.etree (or cElementTree,
for that purpose), as the latter two were specifically designed for high
performance and a much simpler API.

Stefan