------- Additional Comments From steven at gcc dot gnu dot org 2005-01-26
11:36 -------
It would be a Good Thing to look at the hash function. The number of
collisions per search is extremely high:
String pool
entries 128928
identifiers 128928 (100.00%)
slots 262144
bytes 1846k (142k overhead)
table size 2048k
coll/search 0.8518
ins/search 0.2747
avg. entry 14.66 bytes (+/- 17.60)
longest entry 830
There is also still a lot of memory allocated at the end of the compilation:
Memory still allocated at the end of the compilation process
Size Allocated Used Overhead
8 4096 200 120
16 4264k 1211k 91k
64 29M 10M 476k
128 3920k 1472k 53k
256 1240k 519k 16k
512 4084k 2026k 55k
1024 488k 390k 6832
2048 2628k 1998k 35k
4096 1160k 1160k 15k
8192 376k 368k 2632
16384 304k 288k 1064
32768 160k 128k 280
65536 704k 640k 616
131072 384k 384k 168
262144 512k 512k 112
524288 512k 512k 56
112 26M 19M 373k
208 63M 43M 883k
48 27M 14M 443k
32 18M 10M 337k
80 13M 13M 186k
Total 199M 122M 2982k
Note especially the 43MB. All of that is in the et-forest alloc-pools.
Perhaps we should allocate/free them per function.
Finally, we allocate a lot of SSA_NAMEs, and varrays are problematic as
always:
source location Garbage Freed
Leak Overhead Times
varray.c:170 (varray_grow) 39485908: 3.3%
280747780:47.6% 229448: 0.2% 80866528:32.0% 552682
tree-ssanames.c:197 (make_ssa_name) 94292264: 7.9% 0:
0.0% 0: 0.0% 8572024: 3.4% 1071503
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
