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