This is the mail archive of the
mailing list for the GCC project.
Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion
On 8/13/12, Elmar Krieger <firstname.lastname@example.org> wrote:
> Good news, and especially the -ftime-report trick was highly useful.
> For example, I got a huge slowdown also with this compiler:
> gcc44 (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
> Copyright (C) 2010 Free Software Foundation, Inc.
> which spends all its time in 'variable tracking':
> variable tracking : 126.07 (89%) usr 0.26 ( 7%) sys 126.50 (87%)
> wall 20647 kB ( 6%) ggc
> TOTAL : 141.94 3.66 145.61
> 336368 kB
> real 2m26.703s
> And the Google Android compiler I reported originally...
> i686-linux-android-gcc (GCC) 4.6.x-google 20120106 (prerelease)
> Copyright (C) 2011 Free Software Foundation, Inc.
> ...which takes more than twice as long spends its time here:
> phase cgraph : 347.75 (100%) usr 10.73 (76%) sys 358.51 (99%)
> wall 130837 kB (84%) ggc
> phase generate : 347.85 (100%) usr 10.77 (76%) sys 358.64 (99%)
> wall 132490 kB (85%) ggc
> var-tracking dataflow : 284.34 (82%) usr 0.00 ( 0%) sys 284.21 (78%)
> wall 0 kB ( 0%) ggc
> TOTAL : 350.04 12.53 362.60
> 155292 kB
> real 6m3.567s
> I really didn't expect that RedHat and Google both mess up GCC with
> their modifications, so I'll report it to them instead ;-)
> Anyway, please send by private email your favorite way of receiving the
> promised 100 USD. Could be PayPal, a list of Amazon.com items which are
> sent to your address, a direct bank transfer etc..
Huge system times like that are really unusual. The most likely
cause is that your system is running out of physical memory and
doing lots of paging. If so, there are some solutions.
(1) Get more memory for the machine.
(2) Compile at lower levels of optimization.
(3) Partition your application into smaller source files, as measured
by the size of the preprocessed file that they expand into.