This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PCH, and more generally C++ parser performance
On Fri, Aug 25, 2000 at 12:56:19AM -0700, Daniel Berlin wrote:
> However, as I said before, if you can reduce the amount of memory we have
> to go through, in any way, it's a much better optimization (in terms of
> usefulness) at this point than optimizing the GC in any way (which is
> always optimization to try to not check as much memory as we would without
> a given GC optimization).
I just discovered ggc_print_statistics. Here's what it says when
called at the very end of compilation - just before free_reg_info().
[I hacked it up to scale things into kbytes/Mbytes for readability.
Then I sorted the output by percentage.]
Tree Number Bytes % Total
identifier_node 97271 5.94M 16.603
parm_decl 42861 5.23M 14.632
function_decl 30924 3.77M 10.557
var_decl 24251 2.96M 8.279
const_decl 15216 1.86M 5.195
tree_list 55848 1.70M 4.766
method_type 12861 1.57M 4.391
integer_cst 48741 1.49M 4.160
field_decl 11761 1.44M 4.015
function_type 9924 1.21M 3.388
binding 37953 1.16M 3.239
result_decl 8103 1012.88k 2.766
string_cst 24251 757.84k 2.070
decl_stmt 24249 757.78k 2.070
type_decl 5704 713.00k 1.947
scope_stmt 16166 505.19k 1.380
block 16166 505.19k 1.380
pointer_type 3706 463.25k 1.265
record_type 3650 456.25k 1.246
reference_type 3641 455.12k 1.243
tree_vec 4574 377.88k 1.032
nop_expr 8083 252.59k 0.690
indirect_ref 8083 252.59k 0.690
compound_stmt 8083 252.59k 0.690
enumeral_type 2010 251.25k 0.686
return_stmt 6054 189.19k 0.517
init_expr 6054 189.19k 0.517
overload 10920 170.62k 0.466
array_type 198 24.75k 0.068
integer_type 135 16.88k 0.046
vector_type 5 640.00 0.002
real_type 5 640.00 0.002
void_type 3 384.00 0.001
namespace_decl 3 384.00 0.001
lang_type 2 256.00 0.001
complex_type 4 512.00 0.001
boolean_type 1 128.00 0.000
error_mark 1 16.00 0.000
Total 547465 35.76M
RTX Number Bytes % Total
mem 55229 862.95k 66.454
symbol_ref 55412 432.91k 33.337
const_int 201 1.57k 0.121
const_double 21 672.00 0.051
reg 27 432.00 0.032
code_label 1 64.00 0.005
pc 1 4.00 0.000
cc0 1 4.00 0.000
Total 110893 1.27M
Log Allocated Used
2 4.00k 60.00
3 452.00k 437.65k
4 1.28M 1.21M
5 11.35M 8.05M
6 8.80M 8.72M
7 22.08M 21.50M
8 84.00k 83.00k
Total bytes marked: 41932084
Total bytes mapped: 46182400
It definitely looks like reducing the size of *_DECL nodes would help.
Also *_TYPE nodes and identifiers, if we can swing it. (This report
doesn't count any strings, or the structures created by cpphash.c for
the identifier table.)
I'm a bit surprised at the size and number of INTEGER_CST nodes.
Aren't they being allocated uniquely? (looks) No they aren't, I was
thinking of CONST_INTs. Maybe I'll make INTEGER_CSTs be allocated
uniquely too. A bit of perl hackery indicates that there are 14,444
integer constants in the code being processed, but only 177 different
values.
zw