------- Additional Comments From steven at gcc dot gnu dot org 2004-12-29 13:09 ------- Trivial 6MB win: Index: parser.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v retrieving revision 1.298 diff -u -r1.298 parser.c --- parser.c 23 Dec 2004 22:07:01 -0000 1.298 +++ parser.c 29 Dec 2004 13:06:30 -0000 @@ -190,7 +190,7 @@ (cp_token *, cp_token *); /* Manifest constants. */ -#define CP_LEXER_BUFFER_SIZE 10000 +#define CP_LEXER_BUFFER_SIZE 160000 #define CP_SAVED_TOKEN_STACK 5 /* A token type for keywords, as opposed to ordinary identifiers. */ This does not fix the underlying problem that the buffer resizing in GC space gives a quadratic behavior in storage allocation, but it avoids it for most files, and it gives a ~2% speedup at -O0 on my box. Stats for cp_lexer_new_main for the test case from PR8361 (-O0): Before: source location Freed Leak Overhead Times cp/parser.c:263 728576: 1.2% 0: 0.0% 204288: 0.5% 1 cp/parser.c:278 45171712:71.7% 0: 0.0% 12665856:29.2% 5 cp/parser.c:253 72: 0.0% 0: 0.0% 8: 0.0% 1 After: source location Freed Leak Overhead Times cp/parser.c:263 11657216:22.4% 0: 0.0% 3268608: 8.1% 1 cp/parser.c:278 23314432:44.8% 0: 0.0% 6537216:16.2% 1 cp/parser.c:253 72: 0.0% 0: 0.0% 8: 0.0% 1 Perhaps we should look for an altogether different data structure for the token buffer - some kind of vector of smaller buffers perhaps.
-- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850
