Raymond Hettinger added the comment: > "you have to provide a benchmark"
Actually, I don't. When making a small series of changes, benchmarking every step is waste of time and tends to trap you in local minimums and causes you to overfit to a particular processor, compiler, or benchmark. The better process is to carefully work through what the code is telling the machine to do and evaluating whether those steps make sense. This is done in conjunction with organizing the code in a more logical manner (i.e. only saving the so->table in the block where we're using it as a check to check if the rich comparison rearranged the table in a way the invalidated the entry pointer or made the current search invalid). In general, less work is better, having related actions take place close together is better, making functions self-contained is better, etc. If you want to team-up and help, your contribution is welcome. General sniping isn't helpful at all. I wrote all of this code and have maintained it for 13 years -- this series of refactorings has been something I've been working towards for a long time. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24681> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
