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. -Howard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
