Memory Usage for XML output is very high

[whart222]

For my project (Gromacs) the memory usage of gcovr is extremely high when using the XML output (-x). It tops at about 1GB. This is with the version from https://software.sandia.gov/trac/fast/export/2745/gcovr/trunk/scripts/gcovr

(from ticket 3922)

[whart222]

Memory is an issue, but seeing as there is no test case demonstrating the problem and the reporter did not provide an address for correspondence, this is getting bumped down in priority.

The one thought that comes to mind is to move to stream-based XML generation instead of the current DOM-based approach for generating the XML. The DOM-based approach we are using now ends up with 2 full copies of the whole project's coverage information in memory at once (one for the data collection, and one for the DOM model).

[TiloW]

I'm facing a similar issue with gcovr 3.2 using too much memory for XML output.
This is especially problematic for me because it increases build time due to swapping.

I've compared the three generators on my local machine (which has sufficient memory).

	*.gcov	*.gcno
Number of Files	388	612
Size of Files [MB]	14	141

	Plain Text	HTML	XML
Peak Memory [KB]	94280	97076	2505896
Runtime	2.70	2.01	3.74

As you can see, runtime is generally not a problem but memory usage is.
XML output uses 25 times the memory of any other generator.

Is there a special reason for using MiniDom instead of ElementTree or lxml?