<div dir="ltr"><div>Another _possible_ performance improvement that is staring us in the face is that 2*b could be replaced with b<<1. Given that b+b (an earlier suggestion of mine) involves two table look-ups for b, whereas b<<1 only involves one, it seems that the scope here for improvement is significant.<br><br></div>By the way, I hope this post is not "top-posted" as my previous one was. Apologies for that - I am new to this kind of thing.<br><br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 12:46 AM, Dave Angel <span dir="ltr"><<a href="mailto:davea@davea.name" target="_blank">davea@davea.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/25/2014 02:31 PM, Serhiy Storchaka wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
п'ятниця, 21-лис-2014 08:15:57 ви написали:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This looks very good indeed. As a matter of interest, is there any<br>
particular reason you have used 2*b instead of b+b? Might b+b be faster<br>
than b*2?<br>
</blockquote>
<br>
Yes, it is slightly faster, but the effect is indiscernible in total<br>
time. But<br>
there is not harm to use b+b.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, in various lines, you use //2. Would >>1 be quicker? On reflection,<br>
perhaps you have had to use //2 because >>1 cannot be used in those<br>
situations.<br>
</blockquote>
<br>
I thought this effect would be insignificant too. But actually it is<br>
measurable<br>
(about 10% for some input). Thanks, this optimization is worth to be<br>
applied.<br>
<br>
</blockquote>
<br></div></div>
Unfortunately, for many values, the version of the function with >>1 is slower.  It's only when the argument is bigger than 10**40 that it's as much as 1% faster.  But it's true that for really large values, it's quicker.<br>
<br>
A quick test shows that 3.3 is about 20% faster for both these functions than 2.7.<br>
<br>
My oversight earlier was assuming a native type.  Once you get into "longs" which aren't supported by the processor, the shift will likely become much faster than divide.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
DaveA<br>
-- <br>
<a href="https://mail.python.org/mailman/listinfo/python-list" target="_blank">https://mail.python.org/<u></u>mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br></div>