Hi Ullrich, Thank you for your fast answer!
On Wednesday, October 30, 2013 6:47:33 PM UTC+1, Ullrich Hafner wrote: > > > This seems to be the problem! The build.xml file should be as small as > possible since these files are always read (and are always kept in memory). > Seems that these plug-ins do not use an additional file to store the data: > this is a bug (or at least a bad design). Can you please file a new bug > report for both plug-ins? > I found 2 earlier bug reports, and added to them cppcheck JENKINS-17363 <https://issues.jenkins-ci.org/browse/JENKINS-17363> Ludicrously slow load time [with lazyloading]<https://issues.jenkins-ci.org/browse/JENKINS-17363> sloccount JENKINS-4769 <https://issues.jenkins-ci.org/browse/JENKINS-4769> Memory consumption is huge <https://issues.jenkins-ci.org/browse/JENKINS-4769> > > Is the performance better if you disable the cppcheck and sloccount > plugins? What other warnings are you aggregating in the analysis.xml file? > Are these produced by the warnings plugin? > I removed the sloccount data and trimmed the cppcheck data as it was too valuable to toss away, but won't be checking for style errors there anymore. The build.xml files now only max out at 300K instead of 13MB. After reloading Jenkins I saw that the heap was reduced from ~700MB to ~300MB and the "All" view is fast again. As you suggested, the compiler warning with it's separate analysis.xml is not the culprit and follows the right approach. I suggested in those two issues that these plugins also follow that strategy. Best Regards, Ruben -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
