[PATCH] D16726: [Profiling] Speed up unittests by ~5x

[Xinliang David Li via llvm-commits]

1024 is not a magic number -- but we are micro-optimizing testing
resources here which is also pointless. I am fine with 3 of course.

David

On Fri, Jan 29, 2016 at 5:11 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
> On Fri, Jan 29, 2016 at 5:05 PM, David Li via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>>
>> davidxl added a comment.
>>
>> please do not remove the no compression path. I think we should just keep
>> your original change of making the iteration to a smaller number.  With the
>> latest change plus 1024 iteration, the test time is ~20ms. I am ok with
>> shorten the iteration further if we think 20ms is too costly.
>
>
> I can understand the value in testing the compression codepath (though it
> seems useful to actually test that it does anything - just testing that it
> roundtrips doesn't seem to demonstrate that the flag is actually causing the
> code to do anything different from when compression is disabled), but I
> still don't understand the point of the 1024 iterations.
>
> My point of concern is not about whether we can afford 20ms, it's about
> whether there's something we're getting out of that. What extra coverage is
> the test providing by dealing with 1024*3 things rather than 3?
>
> - David