Showing content from http://mail.python.org/pipermail/python-dev/attachments/20161010/2b73f811/attachment.html below:
<div dir="ltr"><div><div>I'd like to reply to both questions with one email, if that's all right. <br><br>Bernardo Sulzbach asked, "How does this interfere with sorting very small
lists?", and ChrisA asked, "How much slower are sorts of
heterogeneous lists?". I modified the benchmark to answer both questions, the former at the top, and the latter at the bottom (see the git repo):<br><br>*** 10 ints ***<br>F.fastsort(): 2.86102294921875e-06<br>F.sort(): 3.337860107421875e-06<br>*** 10 strings ***<br>F.fastsort(): 1.6689300537109375e-06<br>F.sort(): 1.6689300537109375e-06<br>*** 1e3 ints ***<br>F.fastsort(): 0.00013589859008789062<br>F.sort(): 0.00018906593322753906<br>*** 1e3 strings ***<br>F.fastsort(): 0.0002529621124267578<br>F.sort(): 0.0002772808074951172<br>*** 1e7 ints ***<br>F.fastsort(): 5.472854375839233<br>F.sort(): 7.8826072216033936<br>*** 1e7 strings ***<br>F.fastsort(): 10.104042053222656<br>F.sort(): 13.139304876327515<br>*** 1e7 ints + 1 float (to disable the optimization while keeping the precheck)***<br>F.fastsort(): 7.57237982749939<br>F.sort(): 7.666172504425049<br></div><br></div><div>ChrisA suggested I also try "make test" or something to get a more realistic benchmark. I will do that once I implement this as a patch, right now it's an extension module that subclasses list, so I can't just drop it into existing code without modification.<br><br></div>Let me know if you have any other questions/suggestions!<br><br><div><div><div><div class="gmail_quote"><div dir="ltr">On Mon, Oct 10, 2016 at 12:18 AM Elliot Gorokhovsky <<a href="mailto:elliot.gorokhovsky@gmail.com">elliot.gorokhovsky@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Hi,<br class="gmail_msg"><br class="gmail_msg"></div>I posted here a while back asking what you guys thought about implementing radix sort for strings in list.sort(). You gave me a lot of reasons why that would be a bad idea. However, it got me thinking, and I came up with something that you may find interesting. <br class="gmail_msg"><br class="gmail_msg"></div>First, some simple benchmark results (numbers are seconds, check out the extension module at <a href="https://github.com/embg/python-fast-listsort.git" class="gmail_msg" target="_blank">https://github.com/embg/python-fast-listsort.git</a>):<br class="gmail_msg"><br class="gmail_msg">*** 1e3 ints ***<br class="gmail_msg">F.fastsort(): 0.00018930435180664062<br class="gmail_msg">F.sort(): 0.0002830028533935547<br class="gmail_msg">*** 1e3 strings ***<br class="gmail_msg">F.fastsort(): 0.0003533363342285156<br class="gmail_msg">F.sort(): 0.00044846534729003906<br class="gmail_msg">*** 1e7 ints ***<br class="gmail_msg">F.fastsort(): 5.479267358779907<br class="gmail_msg">F.sort(): 8.063318014144897<br class="gmail_msg">*** 1e7 strings ***<br class="gmail_msg">F.fastsort(): 9.992833137512207<br class="gmail_msg">F.sort(): 13.730914115905762<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The optimization uses the fact that, in practice, we are almost always sorting keys of the same type (note: not objects of the same type, *keys* of the same type; we could have a complex key function like str that takes many different types, but the keys are still all the same type). So we can just do one typecheck up front and then do unsafe comparisons during the sort (if our initial check passes). Specifically, we check that for all the PyObject* in saved_ob_item, the ob->ob_type are the same. Then we replace PyObject_RichCompare with ob_type->tp_richcompare. Additionally, we can check for the very common cases of ints and strings and give optimized comparison functions for those cases. It might not seem like this would save a lot of time, but it turns out that PyObject_RichCompare is a massive clusterf**k that has to test tons of type stuff before it can actually compare. Cutting that out ends up saving a *lot* of time, as the benchmark demonstrates.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What do you think? I'm planning on writing this up into a patch, but wanted to get some feedback on the implementation and ideas for improvement first.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks,<br class="gmail_msg"></div><div class="gmail_msg">Elliot<br class="gmail_msg"></div><br class="gmail_msg"></div></div></div></blockquote></div></div></div></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4