This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
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"
Fix: Fixed in GCC 3.3, GCC 3.4 with: http://gcc.gnu.org/ml/gcc-patches/2003-03/msg01537.html
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!
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 |
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
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
State-Changed-From-To: analyzed->closed State-Changed-Why: Fixed for 3.3.