[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

[Douglas Gregor]

On Jan 26, 2009, at 6:57 PM, Howard Hinnant wrote:

> On Jan 26, 2009, at 6:55 PM, Douglas Gregor wrote:
>
>>
>> On Jan 21, 2009, at 11:52 AM, 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?
>>>
>>> It would be nice if someone could inspect the code generation for  
>>> the
>>> smart pointers to see if there is any performance we can reclaim.
>>
>> Now that the low-level optimizations for DISABLE_SMART_POINTERS in  
>> r63061are in, I went back to revisit r62475 to see if it's hurting  
>> us.
>>
>> When smart pointers are *enabled*, parsing Cocoa.h (with PTH, - 
>> disable-free, and -fsyntax-only) is 3% slower due to r62475. So  
>> smart pointers have some cost when they're enabled (as we'd expect).
>>
>> When smart pointers are *disabled*, parsing Cocoa.h (with PTH, - 
>> disable-free, and -fsyntax-only) is .2% slower due to r62475.  
>> That's in the noise on my system, so smart pointers have a  
>> negligible cost when they're disabled (as we'd hoped).
>>
>> I've attached a patch that can be used to roll back r62475 for this  
>> kind of performance testing (if anyone else wants to try to  
>> duplicate my results), but I have no intent on ever applying it.  
>> DISABLE_SMART_POINTERS seems to do the job for our purposes.
>>
>> We've inspected the code generated by smart pointers and raw  
>> pointers with the smart pointer functionality disabled (i.e.,  
>> DISABLE_SMART_POINTERS is defined) in a micro-benchmark of pointer- 
>> passing through the Action interface, and GCC is producing  
>> relatively good code. In the micro-benchmark, use of the smart  
>> pointer classes when the smart-pointer functionality is disabled  
>> only results in a 2% slowdown.
>>
>> The micro-benchmark itself is attached; apply it to Clang and run  
>> Clang on a file containing a single integer to get some simple  
>> measurements, e.g.,
>>
>> Smart pointer time = 0.021950s
>> Raw pointer+ExprResult time = 0.025072s
>> Raw pointer time = 0.021499s
>
> Just out of curiosity:  Is there a correctness difference between  
> these configurations?  I.e. does one leak more memory than another?   
> It is always more expensive to call delete than not to.

Yes, there is. When smart pointers are enabled (DISABLE_SMART_POINTERS  
is not defined), we shouldn't leak anything.[*] With smart pointers  
are disabled (DISABLE_SMART_POINTERS is defined), we will leak AST  
nodes when there is some kind of parsing or semantic error.

This behavior is intentional. We also have -disable-free, which tells  
the compiler not to free its ASTs at the end of execution, since the  
process is terminating anyway. We've also experimented with using  
LLVM's BumpPtrAllocator, which gives us much faster allocation (but we  
don't bother to free).

	- Doug

[*] We still do leak quite a few AST nodes, but we're working on  
fixing that as part of cleaning up the ownership model.