[Bug c++/101163] slow compilation for huge classes (>20k members functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163 --- Comment #5 from René Bürgel --- Do I get that right, that this procedure is done for *every* member when adding it? So, this would make it basically quadratic...
[Bug c++/101164] slow compilation for huge classes (>200k member variables)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101164 --- Comment #5 from René Bürgel --- Thanks for the explanations
[Bug c++/101164] slow compilation for huge classes (>200k member variables)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101164 --- Comment #2 from René Bürgel --- it might be worth taking a look how the C frontend handles it and why this issue doesn't exist there? Just guessing...
[Bug c++/101164] New: slow compilation for huge classes (>200k member variables)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101164 Bug ID: 101164 Summary: slow compilation for huge classes (>200k member variables) Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rbuergel at web dot de Target Milestone: --- Created attachment 51049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51049=edit clean example similar to bug #101163, this also happens for member variables. What puzzles me here: using gcc instead of g++ works perfectly fine g++-4.9 slow-member-var.c -ftime-report Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1445 kB ( 7%) ggc phase parsing : 7.96 (100%) usr 0.16 (100%) sys 8.14 (100%) wall 18470 kB (92%) ggc phase finalize : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc |name lookup: 7.74 (97%) usr 0.07 (44%) sys 7.82 (96%) wall 2073 kB (10%) ggc preprocessing : 0.00 ( 0%) usr 0.06 (38%) sys 0.07 ( 1%) wall 5046 kB (25%) ggc parser (global) : 0.02 ( 0%) usr 0.02 (12%) sys 0.03 ( 0%) wall 3886 kB (19%) ggc parser struct body : 7.94 (100%) usr 0.08 (50%) sys 8.04 (99%) wall 9536 kB (48%) ggc TOTAL : 7.96 0.16 8.15 19975 kB gcc-4.9 slow-member-var.c -ftime-report Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1124 kB ( 9%) ggc phase parsing : 0.12 (100%) usr 0.10 (100%) sys 0.22 (100%) wall 10866 kB (90%) ggc preprocessing : 0.04 (33%) usr 0.03 (30%) sys 0.07 (32%) wall 4811 kB (40%) ggc lexical analysis: 0.05 (42%) usr 0.02 (20%) sys 0.08 (36%) wall 0 kB ( 0%) ggc parser struct body : 0.03 (25%) usr 0.05 (50%) sys 0.07 (32%) wall 5951 kB (49%) ggc TOTAL : 0.12 0.10 0.22 12045 kB
[Bug c++/101163] slow compilation for huge classes (>20k members)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163 --- Comment #1 from René Bürgel --- -ftime-report for trunk-gcc says: Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 1562k ( 4%) phase parsing : 4.75 (100%) 0.11 (100%) 5.09 (100%) 36M ( 96%) |name lookup : 4.51 ( 95%) 0.05 ( 45%) 4.76 ( 93%) 2088k ( 5%) garbage collection : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) preprocessing : 0.04 ( 1%) 0.05 ( 45%) 0.07 ( 1%) 4449k ( 12%) parser (global): 0.02 ( 0%) 0.00 ( 0%) 0.04 ( 1%) 3647k ( 9%) parser struct body : 4.63 ( 97%) 0.05 ( 45%) 4.91 ( 96%) 9128k ( 24%) symout : 0.05 ( 1%) 0.01 ( 9%) 0.06 ( 1%) 19M ( 51%) TOTAL : 4.75 0.11 5.10 37M It seems to be an issue in the name lookup, if I interpret that right...
[Bug c++/101163] New: slow compilation for huge classes (>20k members)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163 Bug ID: 101163 Summary: slow compilation for huge classes (>20k members) Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rbuergel at web dot de Target Milestone: --- Created attachment 51047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51047=edit clean example Hi, we have a real-world-use-case using a class with ~20k member functions. Compilation speed decreases awefully when just including that header in another file: from 2 to 60 seconds. we're using gcc-6.3 in production, but i tested other versions on https://godbolt.org/ clang doesn't seem to have that problem, but it seems to be present in newer gccs, too
