Re: ggc_pop_context speedup

[Mike Stump <mstump at apple dot com>]

On Thursday, January 30, 2003, at 12:32 AM, Geoff Keating wrote:
> - Please make sure your comments are wrapped to 80 characters in the 
> file.
Done.

> - Please use a mailer that does not word-wrap your patches.
I did include an attachment with the patch, but I also included the cut 
and paste before it.  I'll leave the cut and paste out.

> - Your description in the ChangeLog of the change to free_page says
>   "Switch over to" but no support for the old data structures is 
> removed,
>   so use wording like "Update" or "Add support for".
Updated.  Now reads `Add support for and use faster data structures.'

> - Please don't use varrays like this.  The intent is that in the future
>   all varrays will be GCed, so adding a case where they must not be 
> GCed
>   will mean that the existing hackery has to be preserved forever.
?  Not sure what to do about this one, can we push this until later?  
In the end, we either lower the code into malloc/realloc or replicate 
varrays for non GCed data structures.

> - Would I be correct in saying that this adds about 120k to the
>   minimum memory footprint of the compiler?  That seems like a lot.
We can tune the initial PTE count down to 10, if we wanted to.  I 
tested small files and they don't notice it either way.  For large 
files, cutting this down to 10 might make compilations a hair slower, 
though, reallocing to 15000*4 bytes doesn't take all that long, and the 
cost would be well hidden in the cost of the large file anyway.

Do you have a number you'd rather see?  The previous number is either 
the maximal or 1/2 the maximal number I saw with a large C++ 
application (Finder_FE).

> - What performance effect does this patch have on typical source code?
95% reduction in the cost of ggc_pop_context.  I'd expect a 0-3% win.

> - Did you test this with --enable-checking=gc,gcac?
I regtested with gc.  gcac shouldn't make a difference.

Any objections to checking it in?