<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 9:22 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Mar 22, 2016, at 8:59 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Tue, Mar 22, 2016 at 8:53 AM, Mehdi Amini via llvm-commits<span> </span><span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>> On Mar 22, 2016, at 8:36 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>><br>> dblaikie added inline comments.<br>><br>> ================<br>> Comment at: unittests/ADT/DenseMapTest.cpp:367<br>> @@ +366,3 @@<br>> +// buckets to insert N items without increasing allocation size.<br>> +TEST(DenseMapCustomTest, InitialSizeTest) {<br>> +  for (unsigned Size = 1; Size <= 1024; ++Size) {<br>> ----------------<br>> If both the ctor and reserve now use common code, might not be necessary to test all parts of that code through both access points.<br><br></span>The point of unit testing is also to make sure no future change breaks a user facing expectation, so it is not totally useless.<br>But the reserve case should also include a test for a map that would already contains element, or a map initialized with some size, then reserved with an extra size.<br></blockquote><div><br></div><div>Sure - it seems like the reserve case would test a superset of the ctor case. I'd be inclined just to test one or two cases in the ctor, then implement it in such a way that it's mostly just "calls reserve".<br></div></div></div></blockquote><div><br></div></span><div>Note that the implementation of the ctor *does not* call reserve(), it calls init() instead which deals with initial setup and calls allocateBuckets(), while reserve() on the other side calls grow(). I refactored the code that compute the number of buckets for a desired number of entries reserved, but this is the only thing shared.</div><span><div><br></div><div><br></div><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>We can't really test all possible implementations today to ensure that future changes don't break the implementation - I agree, there's certainly some balance (testing generic edge cases that are likely to be hiccups, even if they aren't issues for today's algorithm). But I'd like there to be some more specific justification than a fairly unbounded "who knows how it might work tomorrow".<br></div></div></div></blockquote><div><br></div></span><div>The original test was already looping over an arbitrary amount of sizes, I don't know where to draw the line and I don't have any rational to drive any decision here, what do you suggest? </div><div>(I your concern is only runtime I can s/1024/128?)</div></div></div></blockquote><div><br></div><div>The usual approach (unit testing textbooks, college courses, etc - which for sure are an oversimplification at times, I realize) is to test the boundary cases, and representative case from any categories the algorithm implies.<br><br>I would tend to suggest doing just that - whatever the smallest example was that wasn't covered by the original code is what I would test (& I'd probably remove a bunch of the other scattershot tests). Sounds like, from your later comments, that 48 would be the right value. Maybe there are a couple of nearby values across the tipping points in the algorithm? But with the large minimium allocation there aren't so many interesting cases for that bound, I Think...<br><br>(speaking of - should the min of 512 apply when the user specifies a smaller bound? Might be worth allowing the user to pull down the initial allocation if they know they don't need much? Not sure)<br><br>To alleviate the concern that someone might refactor the code in such a way to make the tests invalid, it might be worth adding negative tests - just one test that demonstrates that default-constructing a DenseMap /will/ reallocate at a certain number of insertions? (default construct, insert things, EXPECT no extra move ops, insert the thing that should be beyond the initial allocation size, EXPECT all the extra move ops)<br><br>Do you think that'd be good?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><div><br></div><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br>(for the same reason we don't test, say, reserve after adding an element in each possible way an element can be added - we assume the way elements are added (but not the fact that they were added) is orthogonal to reserve)</div></div></div></blockquote><div><br></div></span><div>"Orthogonality" seems... orthogonal :) to what we're discussing here.</div></div></div></blockquote><div><br></div><div>Somewhat - but what I mean is two codepaths that lead to the same code (insert+reserve or []+reserve for example) don't usually deserve two tests.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><div><br></div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>><br>> ================<br>> Comment at: unittests/ADT/DenseMapTest.cpp:368<br>> @@ +367,3 @@<br>> +TEST(DenseMapCustomTest, InitialSizeTest) {<br>> +  for (unsigned Size = 1; Size <= 1024; ++Size) {<br>> +    DenseMap<unsigned, CountCopyAndMove> Map(Size);<br>> ----------------<br>> Do we need to test it for all these values? Or could we be a bit more specific? (I worry about shotgun testing like this - hard to maintain (because it's not clear what cases it's testing) & can add time to our test runs, make them harder to debug (because they're doing so much unintended/unnecessary work), etc)<br><br></span>Runtime is 5ms for this test.<br>Yeah that's annoying, we could do a bit more "white box testing", but it is not clear how robust it would be against future change of the internals of the map. What are you suggesting (beside adding a comment)?<br></blockquote><div><br></div><div>Well, what motivated you to choose 1024? </div></div></div></blockquote><div><br></div></span><div>I flipped a coin ;)</div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>Why not 470 (is a power of two significant)? </div></div></div></blockquote><div><br></div></span><div>No good reason to choose a power of two.</div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>or 5 (is such a large number significant)? </div></div></div></blockquote><div><br></div></span><div>Size is significant (see below).</div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>(sorry, I don't mean for that to sound facetious/confrontational, but I'd like to have some justification/discussion when adding test cases (in both directions, to be sure - to make sure we have enough testing, but also not too much)) <br></div></div></div></blockquote><div><br></div></span><div>That's fine! And I don't try to be difficult, I'm really not having any good justification or idea on how to "prune" smartly such a test.</div><div>What I can say is that the bug I fixed showed up only:</div><div><br></div><div>- showed up only for specific values (i.e. 4 * nEntries == 3 * nBuckets).</div><div>- the number of buckets had to be more than 64 (min initial alloc). </div><div><br></div><div>I didn't go with the minimum (48) because someone might figure that a minimum initialization of 512 for the map would be nice, I figure that 1024 was somehow reasonable, not that I was totally happy with it (and it was late last night...).</div></div></div></blockquote><div><br></div><div>No worries - I might not be entirely awake either :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><font color="#888888"><div><br></div><div>-- </div><div>Mehdi</div></font></span><span><div><br></div><div><br></div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>Thanks,<br><br>Mehdi<br><div><div><br><br><br>><br>> ================<br>> Comment at: unittests/ADT/DenseMapTest.cpp:377<br>> @@ +376,3 @@<br>> +    EXPECT_EQ(Size * 2, CountCopyAndMove::Move);<br>> +    EXPECT_EQ((unsigned)0, CountCopyAndMove::Copy);<br>> +  }<br>> ----------------<br>> You could use '0u' for the unsigned 0 literal rather than a cast<br>><br>> ================<br>> Comment at: unittests/ADT/DenseMapTest.cpp:384<br>> @@ +383,3 @@<br>> +TEST(DenseMapCustomTest, ReserveTest) {<br>> +  for (unsigned Size = 1; Size <= 1024; ++Size) {<br>> +    DenseMap<unsigned, CountCopyAndMove> Map;<br>> ----------------<br>> Same question here<br>><br>><br>><span> </span><a href="http://reviews.llvm.org/D18345" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18345</a><br>><br>><br>><br><br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a></div></div></blockquote></div></div></blockquote></span></div><br></div></blockquote></div><br></div></div>