<div dir="ltr">Any chance those performance tests could be checked in?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 17, 2014 at 7:15 PM, Howard Hinnant <span dir="ltr"><<a href="mailto:howard.hinnant@gmail.com" target="_blank">howard.hinnant@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Aug 17, 2014, at 9:22 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca">eric@efcs.ca</a>> wrote:<br>


<br>
> Hi Howard,<br>
><br>
> Thanks for the advice. I'll make sure to performance test these changes without moving forward.<br>
> I also appreciate the insight.<br>
><br>
> > 0 is a valid bucket count.  An upward bump of 0 buckets goes to 2.<br>
> 1 is considered not a power of 2, but it rounded up to 2.<br>
> 2 is considered prime, not a power of 2.  Thus a upward bump off bucket size 2 goes to 5, not 4.<br>
><br>
> Are you referring to the input/output from the __next_power2 function?<br>
> Passing 1 to __next_power2 causes undefined behavior because it passes 0 to __clz.<br>
><br>
> I'll consider just backing out these changes and renaming the functions so they don't imply mathematical accuracy.<br>
<br>
</div>I’m not saying you should back them out.  I honestly don’t know.  I’m just saying one should tread with caution here, and use measurement to guide the way.<br>
<br>
The bottom line is really really how rehash behaves, since the __functions are all implementation details.  And these __functions were purposefully implemented just to serve __hash_table, and are not general purpose facilities.<br>


<span class="HOEnZb"><font color="#888888"><br>
Howard<br>
<br>
</font></span></blockquote></div><br></div>