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

[David Blaikie via llvm-commits]

On Mon, Feb 8, 2016 at 3:17 PM, Xinliang David Li <davidxl at google.com>
wrote:

> On Mon, Feb 8, 2016 at 3:12 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> > 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?)
>
> It tests that the reader is (flexible) and capable of handing padding
> bytes not produced by the writer.  How many paddings should be emitted
> is not specified. For instance, if some producer forces 8 byte
> alignment, it should be handled too.


Ah, OK - perhaps we could just test one pseudo-random (if it's really just
a "while (null byte)" loop to ignore the padding - I'd probably pick 2
bytes of padding, but don't mind any small number) amount of padding to
test that the reader ignores it, rather than testing several amounts of
padding? Alternatively/in addition, might be good to test these features
separately to make triage easier? Rather than combining compression and
padding together - unless there's an interesting interaction between the
two features in the implementation?

You say "padding bytes not produced by the writer" - does the writer
produce zero bytes of padding, or some amount of padding that's just not
the same amounts as are being tested here?

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160208/ddc64f97/attachment.html>