This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
> Synopsis: Compile time increases quadratically with struct size > > State-Changed-From-To: analyzed->closed > State-Changed-By: rth > State-Changed-When: Mon May 12 03:32:46 2003 > State-Changed-Why: > http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00989.html > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10675 I've applied the patch to the gcc-3.3 and manually fixed the conflicts. This does indeed fix the compile-time with gcc, but g++ still behaves quadratically. Also for C++ you may want to run the attached biggen3.sh, that will generate a struct as before, but it adds a constructor that zero-initializes all members. This also have unusually large, although linear memory usage, e.g., the compile of a struct with 25000 members with constructor initializers needs 55M (based on the memory use showed by top on both AIX and Linux). And even C still seems to have slow lookups, as if the hash is only used to detect duplicates, but for member lookup it still uses linear search. Run the attached biggen5.sh to test this, it will create a C struct and a function that initializes the struct. Because of all this, I'd like to reopen this bug, or should I open a new bug? Zoli
Attachment:
biggen3.sh
Description: Text document
Attachment:
biggen5.sh
Description: Text document
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |