<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">LLVM IR times look within reasonable range. Also, please make sure what you are<div>timing has @implementation of classes in them and preferably, with bunch of their </div><div>own private ivars.</div><div><br></div><div>- Thanks, Fariborz</div><div><br><div><div>On Feb 27, 2013, at 9:57 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">Is there a preferred way to report compile-time-performance?<br><br>It seems as if any performance hit introduced by the new patch is within the variance between runs.<br><br>For a large module that includes Cocoa.h, using -O0 -g -ftime-report, I get<span class="Apple-converted-space"> </span><br><br> ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---<br> 3.4411 ( 91.4%) 0.0512 ( 64.9%) 3.4923 ( 90.9%) 3.4922 ( 90.8%) Clang front-end timer<br> 0.1774 ( 4.7%) 0.0097 ( 12.3%) 0.1871 ( 4.9%) 0.1871 ( 4.9%) Code Generation Time<br> 0.1461 ( 3.9%) 0.0180 ( 22.8%) 0.1641 ( 4.3%) 0.1673 ( 4.3%) LLVM IR Generation Time<br> 3.7647 (100.0%) 0.0789 (100.0%) 3.8435 (100.0%) 3.8467 (100.0%) Total<br><br>vs the original<br><br> ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---<br> 3.4252 ( 91.5%) 0.0519 ( 65.0%) 3.4771 ( 90.9%) 3.4770 ( 90.8%) Clang front-end timer<br> 0.1770 ( 4.7%) 0.0100 ( 12.6%) 0.1870 ( 4.9%) 0.1869 ( 4.9%) Code Generation Time<br> 0.1427 ( 3.8%) 0.0179 ( 22.4%) 0.1606 ( 4.2%) 0.1643 ( 4.3%) LLVM IR Generation Time<br> 3.7450 (100.0%) 0.0798 (100.0%) 3.8248 (100.0%) 3.8282 (100.0%) Total<br><br>This is for a Debug+Asserts build.<br><br>For Release I get<br> ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---<br> 0.3109 ( 88.0%) 0.0329 ( 67.8%) 0.3438 ( 85.6%) 0.3438 ( 85.5%) Clang front-end timer<br> 0.0254 ( 7.2%) 0.0057 ( 11.7%) 0.0311 ( 7.7%) 0.0311 ( 7.7%) Code Generation Time<br> 0.0169 ( 4.8%) 0.0099 ( 20.5%) 0.0268 ( 6.7%) 0.0275 ( 6.8%) LLVM IR Generation Time<br> 0.3532 (100.0%) 0.0486 (100.0%) 0.4017 (100.0%) 0.4023 (100.0%) Total<br><br>versus the original<span class="Apple-converted-space"> </span><br><br> ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---<br> 0.3219 ( 88.2%) 0.0335 ( 67.6%) 0.3554 ( 85.8%) 0.3554 ( 85.6%) Clang front-end timer<br> 0.0259 ( 7.1%) 0.0059 ( 11.9%) 0.0318 ( 7.7%) 0.0318 ( 7.7%) Code Generation Time<br> 0.0170 ( 4.7%) 0.0102 ( 20.5%) 0.0272 ( 6.6%) 0.0280 ( 6.7%) LLVM IR Generation Time<br> 0.3648 (100.0%) 0.0496 (100.0%) 0.4144 (100.0%) 0.4152 (100.0%) Total<br><br>All are best out of 3 runs.<br><br>On Feb 27, 2013, at 9:07 AM, jahanian <<a href="mailto:fjahanian@apple.com">fjahanian@apple.com</a>> wrote:<br><br><blockquote type="cite">Not commenting on the DebugInfo caching part. But as a general comment, if there was a performance hit, you may want to<br>provide performance numbers before and after this patch, say on Cocoa.h, and sample of other more modern framework<br>files which use if private ivars (and of course while generating debug info).<br><br>- Fariborz<br><br>On Feb 26, 2013, at 6:08 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br><br><blockquote type="cite">Hi CFEers,<br><br>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.<br>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.<br><br>-- Adrian<br><br><0001-Ensure-that-DIType-is-regenerated-after-we-visited-a.patch>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</blockquote></blockquote></div></blockquote></div><br></div></body></html>