[cfe-commits] r62475 - in /cfe/trunk: Driver/PrintParserCallbacks.cpp include/clang/Parse/Action.h lib/Parse/ParseExpr.cpp lib/Parse/ParseStmt.cpp lib/Sema/Sema.h lib/Sema/SemaChecking.cpp lib/Sema/SemaExpr.cpp lib/Sema/SemaOverload.cpp

[steve naroff]

On Jan 21, 2009, at 1:56 PM, Daniel Dunbar wrote:

> Ok. Are you able/willing to investigate or should I try to con someone
> else into it?
>
> - Daniel
>

Daniel, thanks for staying on top of this issue.

> On Wed, Jan 21, 2009 at 1:33 PM, Sebastian Redl
> <sebastian.redl at getdesigned.at> wrote:
>> Daniel Dunbar wrote:
>>> My performance tester is pointing at this for a 2.5% regression in
>>> syntax only time.  Is this inherent and the price we have to pay for
>>> cleanup, or unexpected?
>>>
>>>
>> Unexpected. I do some very rough performance testing on every bunch I
>> convert and never notice a slowdown. There is an inherent price (the
>> smart pointers carry around a pointer to the Action all the time),  
>> but I
>> expected it to be unnoticeable.
>>

Sebastian, when we decided to move forward with this, we agreed it was  
important to do "A/B comparisons" (see below). By analogy, this  
pattern needs to be like "0-cost" exceptions (where entering a block  
is 0-cost). Parsing valid code should be 0-cost (or darn close to it).

Thanks for understanding our performance goals,

snaroff

Begin forwarded message:
> From: steve naroff <snaroff at apple.com>
> Date: December 19, 2008 8:35:13 AM PST
> To: clang-dev Developers <cfe-dev at cs.uiuc.edu>
> Subject: Smart pointer usage in the Parser/Actions
>
> Folks,
>
> Over the past week or so, there's been some discussion about making  
> extensive use of smart pointers in the parser (on clang-dev).
>
> Since the change is pervasive (and influences the programming  
> model), we discussed the topic yesterday (with Apple compiler  
> engineers working on clang).
>
> We concluded it makes sense to follow-through with the changes. Our  
> only concern is performance: we don't want to degrade performance of  
> parsing correct code. For example, parsing system headers remains a  
> bottleneck. Since system headers don't contain invalid code, it's  
> important this improvement not degrade performance. Once the change  
> is complete, it's important we do "A/B comparisons" to measure the  
> performance for parsing valid code.
>
> Once we have the data, we can decide if the cost is worth the  
> benefit. We don't anticipate a major slowdown, however given the  
> scope of the change (and frequency of calling "move"), it's  
> something we need to verify.
>
> We'd like to thank Sebastian for tackling this project!
>
> snaroff
>
>> Sebastian
>>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20090121/c66d16ab/attachment.html>