This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Faster compilation speed: cache behavior
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Devang Patel <dpatel at apple dot com>
- Cc: Matt Austern <austern at apple dot com>, Neil Booth <neil at daikokuya dot co dot uk>,gcc at gcc dot gnu dot org
- Date: Tue, 20 Aug 2002 16:32:46 -0700
- Subject: Re: Faster compilation speed: cache behavior
- References: <CF56A5CB-B48E-11D6-82FA-00039390D9E0@apple.com> <D714635A-B491-11D6-A5B3-00039310EDEA@>
On Tue, Aug 20, 2002 at 04:09:12PM -0700, Devang Patel wrote:
>
> Number Bytes %Total
> identifier_node 786 49k 35.143
> tree_list 281 5620 4.276
> function_decl 222 24k 18.918
> integer_cst 132 4224 3.214
> type_decl 118 12k 10.056
It's worth keeping in mind that the -fmem-report statistics only count
trees which are still reachable from the GC root set at the end of the
translation unit. In other words, trees and/or RTL that are reclaimed
by garbage collection are not counted at all. I have meant to rectify
this for years now - you're welcome to beat me to it. :-)
Here's an interesting data point: On an *empty* source file, the
current tip of the 3.2 branch (which is what I happen to have a binary
of, to hand) reports
$ ./cc1 -fmem-report test.c
{GC 176k -> 93k}
Tree Number Bytes % Total
error_mark 1 16 0.020
identifier_node 443 27k 36.068
tree_list 114 2280 2.900
void_type 2 240 0.305
integer_type 36 4320 5.496
real_type 3 360 0.458
complex_type 4 480 0.611
vector_type 15 1800 2.290
boolean_type 1 120 0.153
pointer_type 15 1800 2.290
array_type 20 2400 3.053
record_type 16 1920 2.442
function_type 50 6000 7.633
integer_cst 100 3200 4.071
function_decl 152 17k 23.204
type_decl 40 4800 6.106
field_decl 19 2280 2.900
Total 1031 76k
RTX Number Bytes % Total
const_int 129 2064 14.438
const_double 21 1344 9.401
const_vector 19 304 2.126
pc 1 8 0.056
reg 9 180 1.259
mem 208 4160 29.099
symbol_ref 388 6208 43.425
cc0 1 8 0.056
eq 1 20 0.140
Total 777 13k
Size Allocated Used Overhead
8 4096 1832 92
16 12k 8688 180
32 8192 3200 88
64 32k 29k 288
120 48k 43k 384
20 12k 6760 156
Total 116k 93k 1188
String pool
entries 443
identifiers 443 (100.00%)
slots 16384
bytes 4728 (3416 overhead)
table size 64k
coll/search 0.0147
ins/search 0.8128
avg. entry 10.67 bytes (+/- 5.80)
longest entry 36
??? tree nodes created
(No per-node statistics)
obstack permanent_obstack: 0 bytes, 1 chunks
Type hash: size 1021, 75 elements, 0.033784 collisions
That is an awful lot of data allocation activity, and an awful lot of
garbage created, for having done nothing at all.
zw