This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
GC impact (was Re: GCC 3.3, GCC 3.4)
- From: Tim Josling <tej at melbpc dot org dot au>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 07 Feb 2003 17:34:40 +1100
- Subject: GC impact (was Re: GCC 3.3, GCC 3.4)
- Organization: Melbourne PC User Group
I did some more tests, extracting the cc1plus (c++ compliler) component out of
a gcc build
including C++. I.e. how much CPU time did the C++ compiler use?
User CPU times were
Matt's minimal allocator: 114.95 seconds
ggc-page with collection turned off: 131.55
ggc-page unchanged: 158.48
The way ggc-page allocates storage slows things down significantly. We see
that the collections also take a significant amount of time. The total cost of
GC is 37%!
This is across a range of program sizes. The results were consistent for all
but the smallest files where the .01 second granularity made it hard to
interpret.
I also looked at the cc1 (C compiler) component of the build. The results were
similar to the previous results I reported - both the allocation and the
collection by ggc-page are costly.
The benefits of GC are
- Allow certain compiles to fit in memory that would not otherwise fit. Does
anyone have any examples - someone mentioned these were some hairy C++
programs in this category?
- Simplify memory management. I am sceptical of this because my workload on MM
has gone up since GC was introduced.
- Provides infrastructure used for precompiled headers and potentially other
compilation checkpoint type activities. This is valid but it should not be at
the expense of other programs.
Tim Josling