[PATCH] D16726: [Profiling] Speed up unittests by ~5x
David Blaikie via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 8 15:12:41 PST 2016
On Mon, Feb 8, 2016 at 3:08 PM, Xinliang David Li <davidxl at google.com>
wrote:
> On Mon, Feb 1, 2016 at 10:44 AM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> > On Fri, Jan 29, 2016 at 5:58 PM, Xinliang David Li <davidxl at google.com>
> > wrote:
> >>
> >> To clarify, it is not 128 iterations, but creating a symbol table with
> >> 128 entries -- which is a reasonable size.
> >
> >
> > We don't generally test on "realistic" sized inputs in the regression
> suite.
> > We write targeted tests for functionality. Broad testing is done in the
> > test-suite and other integration level testing.
> >
> >>
> >> Test coverage wise, it is probably the same as a 3-entry symtab.
> >
> >
> > Then let's use a 3-entry symtab.
> >
> > (why 3? Because it tests the boundaries (first and last) and one "normal"
> > case of a non-boundary value - while the boundaries probably aren't
> > interesting in this algorithm, it's cheap enough to just follow that
> common
> > practice in test case design)
>
> Will update it to 3.
>
> >
> > I'm also curious about the padding parameter - what does it do? Choose
> how
> > many null characters go between each value? What effect does that
> have/why
> > is that a tuning parameter? (understanding what it's for can help us
> choose
> > appropriate test cases/coverage for that functionality)
>
> Internal padding bytes (for alignment to 4 bytes) can be zero to 3.
Any idea what's particularly useful to test here? (does it just assert that
the parameter is [0,3] ? Or does it have well defined behavior (returning
an error code? doing something else?) outside that range? is any case more
interesting than any other - or just a simple loop for [0,Padding] done at
some point in the algorithm? Does anything test that the algorithm emitted
the right padding?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160208/6e35b3da/attachment.html>
More information about the llvm-commits
mailing list