Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory Usage for XML output is very high #1

Closed
whart222 opened this issue Sep 2, 2013 · 2 comments

Comments

@whart222
Copy link
Member

@whart222 whart222 commented Sep 2, 2013

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

This comment has been minimized.

Copy link
Member Author

@whart222 whart222 commented Sep 2, 2013

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

This comment has been minimized.

Copy link

@TiloW TiloW commented Oct 20, 2015

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.