This is the mail archive of the gcc@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: Suggestion for improving C++ parser memory usage


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


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