[cfe-commits] r125183 - in /cfe/trunk: include/clang/AST/ include/clang/Basic/ lib/AST/ lib/CodeGen/ lib/Sema/ lib/StaticAnalyzer/Checkers/ tools/libclang/

Ted Kremenek kremenek at apple.com
Wed Feb 9 19:21:05 PST 2011


Thanks John.  It looks like a slight speedup, with an overall reduction of memory usage on Cocoa.h of about 0.2 megabytes (I'm looking at the reduction of allocated bytes).

On Feb 9, 2011, at 6:21 PM, John McCall wrote:

> On Feb 9, 2011, at 3:56 PM, Ted Kremenek wrote:
>> Was there a noticeable impact on compile-time?  Memory use?
> 
> "Before my patch" is r125182.  "After my patch" is r125185.  All measurements except one are the median of 3 approximately similar results as generated on a not-very-reliable, not-hardly-quiescent laptop.
> 
> Cocoa_h.m creates 35700 Stmts/Exprs and 85258 Decls.  On a 64-bit platform, this is a theoretical memory savings of 285,600 bytes for Stmts/Exprs and 682,064 bytes for Decls.
>   - Before my patch, it allocated 13,008,896 bytes, of which it used 12,449,976, with the remainder being lost to e.g. alignment padding.
>     A Release build completed 1000 runs (I'm not sure why I did 1000 runs) on my machine with the following characteristics:
>     daysthatwere:clang rjmccall$ runN 1000 ../../Release/bin/clang -fsyntax-only INPUTS/Cocoa_h.m
>     name	  avg  	  min  	  med  	  max  	   SD  	 total 
>     user	 0.3246	 0.3215	 0.3247	 0.3328	 0.0014	324.5585
>     sys	 0.0771	 0.0662	 0.0819	 0.0898	 0.0068	77.1401
>     wall	 0.4064	 0.3954	 0.4088	 0.4440	 0.0071	406.4173
> 
>   - After my patch, it allocated 12,779,520 bytes, of which it used 12,164,576.  This is a memory savings of 284,400 bytes (used).  1,328,392 bytes of Stmt/Expr nodes were allocated overall.

The memory savings I see from your numbers is 13,008,896 - 12,779,520 = 229,376 (from the total allocated bytes).  Isn't this the actual memory savings (not 284,400)?

>     A Release build completed 100 runs on my machine with the following characteristics:
>     daysthatwere:clang rjmccall$ runN 100 ../../Release/bin/clang -fsyntax-only INPUTS/Cocoa_h.m
>     name	  avg  	  min  	  med  	  max  	   SD  	 total 
>     user	 0.3175	 0.3147	 0.3172	 0.3247	 0.0019	31.7507
>     sys	 0.0770	 0.0682	 0.0780	 0.0895	 0.0061	 7.6987
>     wall	 0.3994	 0.3886	 0.3990	 0.4162	 0.0073	39.9351
> 
> 
> all_std_headers.cpp creates 69666 Stmts/Exprs and 35101 Decls.  On a 64-bit platform, this is a theoretical memory savings of 557,328 bytes for Stmts/Exprs and 280,808 bytes for Decls.
>   - Before my patch, it allocated 12,705,792 bytes, of which it used 12,174,357.
>     A Release build completed 100 runs on my machine with the following characteristics:
>     daysthatwere:clang rjmccall$ runN 100 ../../Release/bin/clang -fsyntax-only INPUTS/all-std-headers.cpp 
>     name	  avg  	  min  	  med  	  max  	   SD  	 total 
>     user	 0.3725	 0.3692	 0.3727	 0.3765	 0.0015	37.2507
>     sys	 0.0474	 0.0394	 0.0480	 0.0463	 0.0056	 4.7440
>     wall	 0.4237	 0.4131	 0.4261	 0.4322	 0.0065	42.3729
> 
>   - After my patch, it allocated 12,214,272 bytes, of which it used 11,618,501.  This is a memory savings of 555,856 bytes (used).  2,917,712 bytes of Stmt/Expr nodes were allocated overall.
>     A Release build completed 100 runs on my machine with the following characteristics:
>     daysthatwere:clang rjmccall$ runN 100 ../../Release/bin/clang -fsyntax-only INPUTS/all-std-headers.cpp 
>     name	  avg  	  min  	  med  	  max  	   SD  	 total 
>     user	 0.3684	 0.3657	 0.3672	 0.3705	 0.0017	36.8390
>     sys	 0.0431	 0.0358	 0.0410	 0.0522	 0.0078	 4.3079
>     wall	 0.4160	 0.4069	 0.4119	 0.4265	 0.0086	41.5987
> 
> So if I didn't completely kill any scientific validity with biased selection in my efforts to get around quiescence problems, this is a modest optimization in running time and a fairly significant optimization of memory usage.  Of course, processing headers only stresses the creation of an AST, not queries against it, so (say) a static-analyzer benchmark might be worthwhile.

A benchmark on the static analyzer could be worthwhile.  My expectation is that the difference will be lost in the noise.

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


More information about the cfe-commits mailing list