This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sir-sigurd
Recipients Greg Price, jdemeyer, sir-sigurd
Date 2019-08-25.14:01:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
These last results are invalid :-)

I thought that I was checking _PyLong_FromUnsignedChar() on top of GH-15192, but that wasn't true. So the correct results for LTO build are:

$ python -m perf timeit -s "from collections import deque; consume = deque(maxlen=0).extend; b = bytes(2**20)" "consume(b)" --compare-to=../cpython-master/venv/bin/python
/home/sergey/tmp/cpython-master/venv/bin/python: ..................... 6.93 ms +- 0.04 ms
/home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 3.96 ms +- 0.01 ms
Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 6.93 ms +- 0.04 ms -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 3.96 ms +- 0.01 ms: 1.75x faster (-43%)

But the most important thing is that using PyLong_FromUnsignedLong() instead of _PyLong_FromUnsignedChar() on top of GH-15192 is producing the same results: striter_next() uses small_ints[] directly. However that's not true for bytearrayiter_next(): PyLong_FromUnsignedLong() is called there. I think that's due to how code is profiled so I'm satisfied with these results more or less.

I'm closing existing PR and probably will close this issue soon after GH-15192 will be merged.
Date User Action Args
2019-08-25 14:01:36sir-sigurdsetrecipients: + sir-sigurd, jdemeyer, Greg Price
2019-08-25 14:01:36sir-sigurdsetmessageid: <>
2019-08-25 14:01:36sir-sigurdlinkissue37837 messages
2019-08-25 14:01:35sir-sigurdcreate