This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Dump stats about hottest hash tables when -fmem-report


On Fri, 19 Aug 2011, Tom Tromey wrote:

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.

Hi Tom, thanks for your comments. I'm well aware that I should test on more equipment besides i386 and x86_64 and I certainly plan to. It's just that writing patches is one thing, but advocating them on gcc-patches is an equally hard thing, and I plan on doing the latter correctly after GSOC ends.


As for the technical side of this patch, I've noticed that while in general there is a good gain to be earned from reduced collisions, there is an overhead in htab_traverse() and htab_delete() that iterate over the array. This is evident primarily in var-tracking, which is more htab-intensive than the rest of the compiler alltogether! So I plan to resubmit my patch together with small changes in var-tracking.


Thanks, Dimitris




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]