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