STINNER Victor <vstin...@python.org> added the comment:
Mark: "I'd much prefer not. Every extra fast path check costs time for the
general case, and there's no strong reason to expect people to be dividing by
one. The range code seems like the right place for this optimization, not the
long-divide code."
In this case, I suggest to add a comment in long_div() to explain why there is
no fast-path in long_div(). Otherwise, I am likely to suggest the exact same
optimization in 6 months :-D
I'm thinking at something similar to my comment in ceval.c:
case TARGET(BINARY_ADD): {
PyObject *right = POP();
PyObject *left = TOP();
PyObject *sum;
/* NOTE(haypo): Please don't try to micro-optimize int+int on
CPython using bytecode, it is simply worthless.
See http://bugs.python.org/issue21955 and
http://bugs.python.org/issue10044 for the discussion. In short,
no patch shown any impact on a realistic benchmark, only a minor
speedup on microbenchmarks. */
This comment is the outcome of 2 years of hard work by many developers :-D See
bpo-21955.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41902>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
