Is there a preferred way to report compile-time-performance? It seems as if any performance hit introduced by the new patch is within the variance between runs.
For a large module that includes Cocoa.h, using -O0 -g -ftime-report, I get ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 3.4411 ( 91.4%) 0.0512 ( 64.9%) 3.4923 ( 90.9%) 3.4922 ( 90.8%) Clang front-end timer 0.1774 ( 4.7%) 0.0097 ( 12.3%) 0.1871 ( 4.9%) 0.1871 ( 4.9%) Code Generation Time 0.1461 ( 3.9%) 0.0180 ( 22.8%) 0.1641 ( 4.3%) 0.1673 ( 4.3%) LLVM IR Generation Time 3.7647 (100.0%) 0.0789 (100.0%) 3.8435 (100.0%) 3.8467 (100.0%) Total vs the original ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 3.4252 ( 91.5%) 0.0519 ( 65.0%) 3.4771 ( 90.9%) 3.4770 ( 90.8%) Clang front-end timer 0.1770 ( 4.7%) 0.0100 ( 12.6%) 0.1870 ( 4.9%) 0.1869 ( 4.9%) Code Generation Time 0.1427 ( 3.8%) 0.0179 ( 22.4%) 0.1606 ( 4.2%) 0.1643 ( 4.3%) LLVM IR Generation Time 3.7450 (100.0%) 0.0798 (100.0%) 3.8248 (100.0%) 3.8282 (100.0%) Total This is for a Debug+Asserts build. For Release I get ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.3109 ( 88.0%) 0.0329 ( 67.8%) 0.3438 ( 85.6%) 0.3438 ( 85.5%) Clang front-end timer 0.0254 ( 7.2%) 0.0057 ( 11.7%) 0.0311 ( 7.7%) 0.0311 ( 7.7%) Code Generation Time 0.0169 ( 4.8%) 0.0099 ( 20.5%) 0.0268 ( 6.7%) 0.0275 ( 6.8%) LLVM IR Generation Time 0.3532 (100.0%) 0.0486 (100.0%) 0.4017 (100.0%) 0.4023 (100.0%) Total versus the original ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 0.3219 ( 88.2%) 0.0335 ( 67.6%) 0.3554 ( 85.8%) 0.3554 ( 85.6%) Clang front-end timer 0.0259 ( 7.1%) 0.0059 ( 11.9%) 0.0318 ( 7.7%) 0.0318 ( 7.7%) Code Generation Time 0.0170 ( 4.7%) 0.0102 ( 20.5%) 0.0272 ( 6.6%) 0.0280 ( 6.7%) LLVM IR Generation Time 0.3648 (100.0%) 0.0496 (100.0%) 0.4144 (100.0%) 0.4152 (100.0%) Total All are best out of 3 runs. On Feb 27, 2013, at 9:07 AM, jahanian <[email protected]> wrote: > Not commenting on the DebugInfo caching part. But as a general comment, if > there was a performance hit, you may want to > provide performance numbers before and after this patch, say on Cocoa.h, and > sample of other more modern framework > files which use if private ivars (and of course while generating debug info). > > - Fariborz > > On Feb 26, 2013, at 6:08 PM, Adrian Prantl <[email protected]> wrote: > >> Hi CFEers, >> >> After re-thinking it, here is an updated version of this patch that does not >> completely disable caching for incomplete interfaces. This should minimize >> the performance hit of the previous version. >> Basically I am now storing ObjCInterface-Types in a separate cache, together >> with a “checksum” (really the number of ivars). If we look up the type >> again, I see if the checksum changed and otherwise just return the type from >> the cache. >> >> -- Adrian >> >> <0001-Ensure-that-DIType-is-regenerated-after-we-visited-a.patch>_______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
