This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: gcc 3.3 garbage collector defaults
- From: Matt Austern <austern at apple dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Ziemowit Laski <zlaski at apple dot com>, Neil Booth <neil at daikokuya dot co dot uk>, Benjamin Kosnik <bkoz at redhat dot com>, Andi Kleen <ak at suse dot de>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Tue, 28 Jan 2003 14:00:09 -0800
- Subject: Re: gcc 3.3 garbage collector defaults
On Monday, January 27, 2003, at 04:59 PM, Zack Weinberg wrote:
Matt Austern <austern@apple.com> writes:
When I compare 3.2 and 3.3 on the same file and the same
machine, 3.3 is much slower than 3.2 and a good part of the
extra time, according to -ftime-report, is from the gc. If
those measurements are right (and I think they probably are,
since several other people report similar results), then
there aren't a whole lot of possibilities for what caused
the regression. We now know it wasn't the gc parameters.
What possibilities haven't we ruled out yet?
My bet would be differing allocation patterns causing the GC to do
more work in 3.3.
That would be my guess too. On the other hand, we haven't
found evidence that suggests that the compiler is allocating
much more memory, which would be the obvious possibility.
We've checked this by tuning gc parameters so it doesn't do
a collection until the heap reaches 64MB, and then looking
at -fmem-report. This suggests that 3.2 and 3.3 are using
comparable amounts of memory.
That's not quite a test of how much memory gets allocated,
but, if we've turned off the collector, it shouldn't be so very
different. If allocation patterns have changed, looks like the
change is something more subtle.
If you provide me with a test case I can try
various profiling tools and give a more definite answer.
Zem has made a test case available. If you'd like more test
cases, please let me know.
--Matt