LLVM IR times look within reasonable range. Also, please make sure what you are timing has @implementation of classes in them and preferably, with bunch of their own private ivars.
- Thanks, Fariborz On Feb 27, 2013, at 9:57 AM, Adrian Prantl <[email protected]> wrote: > 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
