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 serhiy.storchaka
Recipients THRlWiTi, christian.heimes, ezio.melotti, gregory.p.smith, martin.panter, methane, n, serhiy.storchaka, terry.reedy
Date 2017-01-04.10:40:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483526440.43.0.687007592469.issue17301@psf.upfronthosting.co.za>
In-reply-to
Content
> The important reasons for this are memory use and cache thrashing, not just
> CPU time.

Memory use is not an issue unless you translate hundreds of megabytes at a time. Cache trashing at the end is performance issue.

The original patch is no longer applied cleanly. Here is a patch synchronized with current sources and with fixed one error. I didn't look at it closely and don't know whether it has other bugs.

Here are results of microbenchmarking.

$ ./python -m perf timeit -s "table = bytes(range(256)).swapcase(); data = bytearray(range(256))*1000" -- "data = data.translate(table)"
Median +- std dev: 1.48 ms +- 0.02 ms
$ ./python -m perf timeit -s "table = bytes(range(256)).swapcase(); data = bytearray(range(256))*1000" -- "data[:] = data.translate(table)"
Median +- std dev: 1.60 ms +- 0.09 ms
$ ./python -m perf timeit -s "table = bytes(range(256)).swapcase(); data = bytearray(range(256))*1000" -- "data.mtranslate(table)"
Median +- std dev: 1.79 ms +- 0.07 ms

In-place translate don't have benefits. It is slower that translate with creating a new copy, and even is slower that translate with copying a new copy back.
History
Date User Action Args
2017-01-04 10:40:40serhiy.storchakasetrecipients: + serhiy.storchaka, terry.reedy, gregory.p.smith, christian.heimes, ezio.melotti, methane, THRlWiTi, martin.panter, n
2017-01-04 10:40:40serhiy.storchakasetmessageid: <1483526440.43.0.687007592469.issue17301@psf.upfronthosting.co.za>
2017-01-04 10:40:40serhiy.storchakalinkissue17301 messages
2017-01-04 10:40:40serhiy.storchakacreate