PATCH: private ivars - update for r176116

[jahanian]

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 <aprantl at apple.com> 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 <fjahanian at apple.com> 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 <aprantl at apple.com> 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
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130227/100325fb/attachment.html>