> Hello list, > > I ported a patch from last year's GSOC to current trunk, removing > deprecated hash tables and adding some new ones. I also backed out a > change that reduced collisions by decreasing load factor because it had > created controversy, so this patch should be easily applicable. > > CC'd whoever is relevant with subsystems or had commented on this last > year. Some notes: > > * Is it OK that I included <assert.h> in libiberty's hashtab.c? > * Many hash tables are created with htab_create_ggc(), for example > referenced_vars and default_defs in tree-ssa.c. I collect statistics in > delete_tree_ssa() but maybe some are not deallocated in there but > automatically garbage collected? > * Obviously hash table sizes are inflated where two entries might > reference the same element (for example in symtab_hash) but I don't > handle this. > * Maybe the best overall solution would be to add a string parameter to > htab_create*() and store statistics in an internal hash table according > to this string. Statistics would then be printed for all hash tables by > iterating this internal table. Since it would cause a significant > slowdown, -fmem-report would be better as a compile-time option than a > run-time one. This is probably an overkill so I think I'll skip it.
You may also consider using the machinery we use for statistics of bitmaps/alloc pools/ vectors/ggc with -fenable-gather-detailes-mem-stats. Will be bit tricky because hashtables are used to gather the stats elsehwere, but i think it is resonable approach to do. (basically you need to add API to avoid gathering statistics of statistics). We should have similar statics for pointer maps and pointer sets. All those are suspects of expoding especially at WPA time. Honza
