Dump stats about hottest hash tables when -fmem-report

[Tom Tromey]

>>>>> "Dimitrios" == Dimitrios Apostolou <jimis@gmx.net> writes:

Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint.  Not sure what is more important here though, memory
Richard> access or hash computation.

Tom> I was only approving the change to the dumping.
Tom> I am undecided about making the hash tables more sparse.

Dimitrios> Since my Core Quad processor has large caches and the i386
Dimitrios> has small pointer size, the few extra empty buckets impose
Dimitrios> small overhead, which as it seems is minor in comparison to
Dimitrios> gains due to less rehashes.

Dimitrios> Maybe that's not true on older or alternate equipment. I'd be
Dimitrios> very interested to hear about runtime measurements on various
Dimitrios> equipment, please let me know if you do any.

I think you are the most likely person to do this sort of testing.
You can use machines on the GCC compile farm for this.

Your patch to change the symbol table's load factor is fine technically.
I think the argument for putting it in is lacking; what I would like to
see is either some rationale explaining that the increased memory use is
not important, or some numbers showing that it still performs well on
more than a single machine.  My reason for wanting this is just that,
historically, GCC has been very sensitive to increases in memory use.
Alternatively, comments from more active maintainers indicating that
they don't care about this would also help your case.

I can't approve or reject the libiberty change, just the libcpp one.

Tom