This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.1 is still very slow, compared to 2.95.3
- From: Mark Mitchell <mark at codesourcery dot com>
- To: "Richard dot Earnshaw at arm dot com" <Richard dot Earnshaw at arm dot com>, Jan Hubicka <jh at suse dot cz>
- Cc: Marc Espie <espie at nerim dot net>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sat, 18 May 2002 10:37:27 -0700
- Subject: Re: gcc 3.1 is still very slow, compared to 2.95.3
- References: <200205181212.NAA00049@cam-mail2.cambridge.arm.com>
--On Saturday, May 18, 2002 01:12:23 PM +0100 Richard Earnshaw
>> I am sorry to say that according to the profiles, there is no single
>> place in GCC where we burn most of the CPU cycles. The slowdown is
>> commulative result of many patches and it is clear that compile time
>> performance has not been thread seriously during GCC development (3.0
>> had number of other problems that were addressed). I personaly will
>> care more the compile time performance in next development and hope we
>> will set up some periodic tester to check this (this has proved to be
>> effective at runtime perfomrance, where 3.1 is very well of).
> I can't prove any of the following, but it seemed to me that the major
> slowdown in the compiler was when we switched from obstacks to ggc.
Yes, this did impose a significant compile-time cost.
I believe it was worth it: there are features we could never have
implemented otherwise, and I have not debugged a g++ memory allocation
bug in years, whereas it used to be weekly occurrence.
On the other hand, I do believe there is a binary order of magnitude
to be had here, by combining (most importantly) reduced memory use and
(less importantly) better allocation and collection strategies.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com