[PATCH] D20993: Add support for collating profiles for use with code coverage

[Vedant Kumar via llvm-commits]

> On Jun 10, 2016, at 5:06 PM, Xinliang David Li <davidxl at google.com> wrote:
> 
> 
> 
> On Fri, Jun 10, 2016 at 4:35 PM, Vedant Kumar <vsk at apple.com> wrote:
> vsk added a comment.
> 
> In http://reviews.llvm.org/D20993#454452, @davidxl wrote:
> 
> > Why choosing default size of 9? Do you have build time comparison numbers i.e., pool size from 1 to 9?
> 
> 
> I chose 9 because it's the highest option: a larger pool of raw profiles should theoretically lead to less lock contention. Ideally this would be some factor of the number of threads on the system. However, I don't think it's worth optimizing this default.
> 
> 
> That is fine. My recollection is that 9 or larger is only needed when network storage system is used. For local HDD, the performance flats out quickly at pool size of 3 or 4 so you get diminishing returns while the storage size cost and post-processing time is increased.  For SSD, 1 is just as good as 2 or higher.

Thanks for sharing this!

I went back and measured the time for check-llvm-unit (4-core iMac, fusion drive):

Size=1: Average 17.20s
Size=4: Average 16.19s
Size=9: Average 16.21s

I think 4 is a more reasonable default, then.

vedant

> 
> 
> David
>  
> > Also, writing it in Python makes it pretty portable for free and is generally more readable.
> 
> 
> Sure, I'll upload a new diff with this change.
> 
> 
> http://reviews.llvm.org/D20993
> 
> 
> 
>