Suggestion for improving C++ parser memory usage

Matt Austern austern@apple.com
Thu Dec 30 19:35:00 GMT 2004


On Dec 30, 2004, at 6:34 AM, Robert Dewar wrote:
> I just don't think you make very much progress by making small
> incremental changes. Yes, I know what 1.01**10 is, but the trouble
> is that many of these changes operate far below the 1% level. I
> am pretty confident that the proposed change is in this category
> though certainly I don't object to someone giving it a try if
> it does not murkify the parser too much.

In practice, we have made significant progress over the last year by 
making small incremental changes.  The 4.0 compiler will be enough 
faster than 3.4 that we'll brag about it in the release notes, and 
almost all of that improvement comes from a series of small changes 
each of which seems uninteresting on its own.  I've seen quite a few 
changes were you can get a .5% -1% improvement in compile speed with a 
week or two of work.  We've made a lot of those improvements already, 
but there are still a lot out there.

That said,... You have to pick which areas to work on,  and I'm not 
convinced that this particular suggestion (reminder: the suggestion is 
to avoid creating scopes in deeply nested if statements when it can be 
shown that new scopes are unnecessary) is a good cost-benefit tradeoff. 
  It would be easy to measure how much time is taken by 
cp_parser_implicitly_scoped_statement and the function it calls.  If it 
turns out to be enough so that this function takes noticeable time when 
compiling typical C++ code (for some plausible definition of typical), 
then it would be worth doing a bit of work to improve it.  I can think 
of a couple of possible ways we might go, including Roger's original 
suggestion.  If this would give us a .5% improvement it would 
definitely be worth it.  If it would give us a .001% improvement, then 
not.  But I don't have a good sense of which it would be.

			--Matt



More information about the Gcc mailing list