<div dir="ltr">If there are robust and simple optimizations that can be added to CPython, great, but:<div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This mail is the consequence of a true story, a story where CPython<br>
got defeated by Javascript, Java, C# and Go.<br></blockquote><div><br></div><div>at least those last three are statically compiled languages -- they are going to be faster than Python for this sort of thing -- particularly for code written in a non-pythonic style...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">def filter(rule, whatever):<br>
    if rule.x in whatever.x:<br>
        return True<br>
<br>
rules = get_rules()<br>
whatevers = get_whatevers()<br>
for rule in rules:<br>
    for whatever in whatevers:<br>
        if filter(rule, whatever):<br>
            cnt = cnt + 1<br>
<br>
return cnt<br>
<br> It's true that they didn't optimize the code, but<br>
they did not for any language having for all of them the same cost in<br>
terms of iterations.<br></blockquote><div><br></div><div>sure, but I would argue that you do need to write code in a clean style appropriate for the language at hand.</div><div> </div><div>For instance, the above creates a function that is a simple one-liner -- there is no reason to do that, and the fact that function calls to have significant overhead in Python is going to bite you.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">for rule in rules:<br>
    x = rule.x<br>
    for whatever in whatevers:<br>
        if x in whatever.x:<br>
            cnt += 1<br>
<br>
The performance of the CPython boosted x3/x4 just doing these "silly" things.<br></blockquote><div><br></div><div>"inlining" the filter call is making the code more pythonic and readable -- a no brainer. I wouldn't call that a optimization.</div><div><br></div><div>making rule.x local is an optimization -- that is, the only reason you'd do it to to make the code go faster. how much difference did that really make?</div><div><br></div><div>I also don't know what type your "whatevers" are, but "x in something" can be order (n) if they re sequences, and using a dict or set would be a much better performance.</div><div><br></div><div>and perhaps <span style="font-variant-ligatures:no-common-ligatures;color:rgb(0,0,0);font-family:Menlo;font-size:11px">collections.Counter </span>would help here, too.</div><div><br></div><div>In short, it is a non-goal to get python to run as fast as static langues for simple nested loop code like this :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The case of the rule cache IMHO is very striking, we have plenty<br>
examples in many repositories where the caching of none local<br>
variables is a widely used pattern, why hasn't been considered a way<br>
to do it implicitly and by default?<br></blockquote><div><br></div><div>you can bet it's been considered -- the Python core devs are a pretty smart bunch :-)</div><div><br></div><div>The fundamental reason is that rule.x could change inside that loop -- so you can't cache it unless you know for sure it won't. -- Again, dynamic language.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The case of the slowness to call functions in CPython is quite<br>
recurrent and looks like its an unsolved problem at all.<br></blockquote><div><br></div><div>dynamic language again ...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> If the default code that you<br>
can write in a language is by default slow and exists an alternative<br>
to make it faster, this language is doing something wrong.<br></blockquote><div><br></div><div>yes, that's true -- but your example shouldn't be the default code you write in Python.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">BTW: pypy looks like is immunized [1]<br>
<br>
[1] <a href="https://gist.github.com/pfreixes/d60d00761093c3bdaf29da025a004582" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>pfreixes/<wbr>d60d00761093c3bdaf29da025a0045<wbr>82</a></blockquote><div><br></div><div>PyPy uses a JIT -- which is the way to make a dynamic language run faster -- That's kind of why it exists....</div><div><br></div><div>-CHB</div><div> </div></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>