[cfe-commits] r99912 - in /cfe/trunk: include/clang/AST/DeclBase.h include/clang/AST/DeclCXX.h include/clang/AST/DeclFriend.h include/clang/AST/DeclObjC.h include/clang/AST/DeclTemplate.h include/clang/AST/Expr.h include/clang/AST/ExprCXX.h include/clang/AST/ExprObjC.h include/clang/AST/Statistics.h include/clang/AST/Stmt.h include/clang/AST/StmtCXX.h include/clang/AST/StmtObjC.h include/clang/AST/Type.h lib/AST/DeclBase.cpp lib/AST/Expr.cpp lib/AST/Stmt.cpp lib/AST/Type.cpp

[Chris Lattner]

On Mar 30, 2010, at 1:41 PM, Douglas Gregor wrote:

>>> 
>>> The statistics are only gathered when NDEBUG is not defined, since
>>> they introduce potentially-expensive operations into very low-level
>>> routines (isa).
>> 
>> Interesting, are these checks (without the instrumentation) expensive and worth optimizing?  What do these metrics tell us?
> 
> Not as much as I'd hoped. Turning all of these checks into a constant "false" (in effect, partly specializing Clang for C code) only yielded a 2.8% performance improvement in -fsyntax-only on some sample C code, so these checks aren't all that expensive.

Ok, is it worth keeping this code?

>> Instead of NDEBUG, how about only enabling it with expensive checks?
> 
> As I understand it, expensive checks is for the *really* expensive checks, like iterator validity via the C++ standard library's debug mode. I don't think we're in that league, but if you're worried about the cost of incrementing a counter per C++/ObjC isa<> in a debug build I can look into it. 

They are atomic increments, so they aren't quite as cheap as they look (it locks the memory bus etc), and people do use release builds sometimes.  *shrug*

-Chris