Bug 8805 - [3.2 regression] compile time regression with many member variables
Summary: [3.2 regression] compile time regression with many member variables
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.1.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog
Depends on:
Blocks:
 
Reported: 2002-12-03 17:46 UTC by ronny
Modified: 2004-12-04 20:23 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
test.ii (37.21 KB, text/x-c++)
2003-05-21 15:16 UTC, ronny
Details
x.cc (8.57 KB, application/octet-stream)
2003-05-21 15:16 UTC, ronny
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ronny 2002-12-03 17:46:01 UTC
C is a class which contains a "vector<int>".
A is a class which contains N C's.
The time for compiling A's constructor (with -O0) scales as approximately N^2.5.  For example, when N=1000 compilation takes 7 secons, when N=2000 compilation takes 39 seconds, when N=4000 compilation takes 270 seconds.
I believe that the compile time should be scaling linearly.
Note that when N=4000, compilation takes only 12 seconds using gcc 2.95.3, so this is a new problem with gcc 3.
Also, the problem does not occur if C contains a plain "int" or a simple templated object instead of a "vector<int>".

Release:
gcc version 3.1.1

Environment:
x86, linux

How-To-Repeat:
compile with "-O0 -c"
Comment 1 ronny 2002-12-03 17:46:01 UTC
Fix:
Fixed in GCC 3.3, GCC 3.4 with:

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01537.html
Comment 2 Wolfgang Bangerth 2002-12-10 15:01:46 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. A simpler testcase using only (nearly) empty
    classes (but made non-POD) is attached. Compile times can be
    made very large by removing the comment signs of a larger
    part of the block of member variables. Here are some timings:
    
    N=500:   gcc2.95: 1s     gcc3.3:  5s
    N=1000:  gcc2.95: 4s     gcc3.3: 20s
    
    So I see a relatively good N**2 behavior, but the
    constant is significantly worse than for 2.95, so I
    rate this a regression. gcc3.2 is somewhere in between,
    about 3 times slower than 2.95, but 25 per cent faster
    than 3.3CVS.
    
    One can play interesting games with this testcase: if
    I _reduce_ the complexity by replacing this code:
    -----
    struct vector { ~vector(); };
    struct C      { C();
                    vector x; };
    
    struct A {
      A();
    
      typedef C T;
    //...
    ------
    
    by
    
    ----
    struct vector { ~vector(); };
    struct C      { C();
                    vector x; };
    
    struct A {
      A();
    
      typedef vector T;
    ---
    (i.e. bypassing the C-class), then the compile times
    _increase_ by a factor of 2 to 3. I would really be
    interested in hearing an explanation of this phenomenon!
Comment 3 ronny 2002-12-12 16:12:35 UTC
From: "Ronny Krashinsky" <ronny@mit.edu>
To: <bangerth@dealii.org>, <gcc-bugs@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>,
   <nobody@gcc.gnu.org>, <ronny@mit.edu>, <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: c++/8805: [3.2/3.3 regression] compile time regression with many member variables
Date: Thu, 12 Dec 2002 16:12:35 -0500

 Thank you for the response.
 Based on your example, I did some more investigation and determined that the
 problem seems to be due to the interaction between member objects with
 destructors and C++ exception handling.  I've come to this conclusion because
 the non-linear increase in compile time does not occur when I compile with
 "-fno-exceptions".  This makes some amount of sense because C++ states that if
 an exception occurs in the middle of initializing the members
 in an object's constructor, then the destructor is called for all the members
 that have already been constructed.  This is an n^2 sort of thing, so it could
 be why the compile times were scaling non-linearly with the number of members.
 So, it seems like this is probably not a bug, but it would be great if gcc were
 better at dealing with code like this.  And, I think that it can still be
 considered a regression since gcc 2.95 is so much faster.
 I don't have write access to the problem report database, so I have not updated
 the report.
 Thanks,
     Ronny
 
 ----- Original Message -----
 From: <bangerth@dealii.org>
 To: <gcc-bugs@gcc.gnu.org>; <gcc-prs@gcc.gnu.org>; <nobody@gcc.gnu.org>;
 <ronny@mit.edu>
 Sent: Tuesday, December 10, 2002 6:01 PM
 Subject: Re: c++/8805: [3.2/3.3 regression] compile time regression with many
 member variables
 
 
 | Old Synopsis: very long (non-linear) compile times for an object with many
 vector<int> members, possibly due to template instantiation
 | New Synopsis: [3.2/3.3 regression] compile time regression with many member
 variables
 |
 | State-Changed-From-To: open->analyzed
 | State-Changed-By: bangerth
 | State-Changed-When: Tue Dec 10 15:01:46 2002
 | State-Changed-Why:
 |     Confirmed. A simpler testcase using only (nearly) empty
 |     classes (but made non-POD) is attached. Compile times can be
 |     made very large by removing the comment signs of a larger
 |     part of the block of member variables. Here are some timings:
 |
 |     N=500:   gcc2.95: 1s     gcc3.3:  5s
 |     N=1000:  gcc2.95: 4s     gcc3.3: 20s
 |
 |     So I see a relatively good N**2 behavior, but the
 |     constant is significantly worse than for 2.95, so I
 |     rate this a regression. gcc3.2 is somewhere in between,
 |     about 3 times slower than 2.95, but 25 per cent faster
 |     than 3.3CVS.
 |
 |     One can play interesting games with this testcase: if
 |     I _reduce_ the complexity by replacing this code:
 |     -----
 |     struct vector { ~vector(); };
 |     struct C      { C();
 |                     vector x; };
 |
 |     struct A {
 |       A();
 |
 |       typedef C T;
 |     //...
 |     ------
 |
 |     by
 |
 |     ----
 |     struct vector { ~vector(); };
 |     struct C      { C();
 |                     vector x; };
 |
 |     struct A {
 |       A();
 |
 |       typedef vector T;
 |     ---
 |     (i.e. bypassing the C-class), then the compile times
 |     _increase_ by a factor of 2 to 3. I would really be
 |     interested in hearing an explanation of this phenomenon!
 |
 |
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=88
 05
 |
 

Comment 4 Mark Mitchell 2003-03-17 06:09:30 UTC
From: mmitchel@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: c++/8805
Date: 17 Mar 2003 06:09:30 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	mmitchel@gcc.gnu.org	2003-03-17 06:09:30
 
 Modified files:
 	gcc            : ChangeLog except.c 
 	gcc/testsuite  : ChangeLog 
 Added files:
 	gcc/testsuite/g++.dg/eh: cleanup1.C 
 
 Log message:
 	PR c++/8805
 	* except.c (eh_region_u_cleanup): Add prev_try.
 	(expand_eh_region_end_cleanup): Set it.
 	(reachable_handlers): Use it to skip over cleanup blocks.
 	
 	PR c++/8805
 	* g++.dg/eh/cleanup1.C: New test.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.17109&r2=1.17110
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/except.c.diff?cvsroot=gcc&r1=1.235&r2=1.236
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.2513&r2=1.2514
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cleanup1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
 

Comment 5 Mark Mitchell 2003-03-17 06:09:30 UTC
From: mmitchel@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: c++/8805
Date: 17 Mar 2003 06:09:30 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	mmitchel@gcc.gnu.org	2003-03-17 06:09:30
 
 Modified files:
 	gcc            : ChangeLog except.c 
 	gcc/testsuite  : ChangeLog 
 Added files:
 	gcc/testsuite/g++.dg/eh: cleanup1.C 
 
 Log message:
 	PR c++/8805
 	* except.c (eh_region_u_cleanup): Add prev_try.
 	(expand_eh_region_end_cleanup): Set it.
 	(reachable_handlers): Use it to skip over cleanup blocks.
 	
 	PR c++/8805
 	* g++.dg/eh/cleanup1.C: New test.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.17109&r2=1.17110
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/except.c.diff?cvsroot=gcc&r1=1.235&r2=1.236
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.2513&r2=1.2514
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cleanup1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
 

Comment 6 Mark Mitchell 2003-03-17 06:12:16 UTC
From: mmitchel@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: c++/8805
Date: 17 Mar 2003 06:12:16 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_3-branch
 Changes by:	mmitchel@gcc.gnu.org	2003-03-17 06:12:16
 
 Modified files:
 	gcc            : ChangeLog except.c 
 	gcc/testsuite  : ChangeLog 
 Added files:
 	gcc/testsuite/g++.dg/eh: cleanup1.C 
 
 Log message:
 	PR c++/8805
 	* except.c (eh_region_u_cleanup): Add prev_try.
 	(expand_eh_region_end_cleanup): Set it.
 	(reachable_handlers): Use it to skip over cleanup blocks.
 	
 	PR c++/8805
 	* g++.dg/eh/cleanup1.C: New test.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.313&r2=1.16114.2.314
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/except.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.233&r2=1.233.2.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.102&r2=1.2261.2.103
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cleanup1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.1.2.1
 

Comment 7 Mark Mitchell 2003-03-17 06:12:16 UTC
From: mmitchel@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: c++/8805
Date: 17 Mar 2003 06:12:16 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_3-branch
 Changes by:	mmitchel@gcc.gnu.org	2003-03-17 06:12:16
 
 Modified files:
 	gcc            : ChangeLog except.c 
 	gcc/testsuite  : ChangeLog 
 Added files:
 	gcc/testsuite/g++.dg/eh: cleanup1.C 
 
 Log message:
 	PR c++/8805
 	* except.c (eh_region_u_cleanup): Add prev_try.
 	(expand_eh_region_end_cleanup): Set it.
 	(reachable_handlers): Use it to skip over cleanup blocks.
 	
 	PR c++/8805
 	* g++.dg/eh/cleanup1.C: New test.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.313&r2=1.16114.2.314
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/except.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.233&r2=1.233.2.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.102&r2=1.2261.2.103
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cleanup1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.1.2.1
 
Comment 8 Joe Buck 2003-04-25 21:32:45 UTC
State-Changed-From-To: analyzed->closed
State-Changed-Why: Fixed for 3.3.