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.

classification
Title: Faster *_find_max_char
Type: performance Stage: resolved
Components: Interpreter Core Versions: Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: pitrou, serhiy.storchaka, vstinner
Priority: low Keywords: patch

Created on 2012-06-22 20:51 by serhiy.storchaka, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
find_max_char_2.patch serhiy.storchaka, 2012-10-17 13:56 review
Messages (5)
msg163480 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-06-22 20:51
Here is patch that speed up *_find_max_char stringlib functions.

Microbenchmarks:

./python -m timeit -s "s='A'*20+'\x80'" "s[:-1]"
./python -m timeit -s "s='A'*20+'\U00010000'" "s[:-1]"

Results on Intel Atom N570 @ 1.66GHz:

vanilla  patched

 0.819    0.73
 0.788    0.755
msg163489 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-06-22 21:18
> 0.819    0.73
> 0.788    0.755

Are there any circumstances where this produces a larger speedup?
I don't think a 10% improvement on a micro-benchmark is interesting at all (it's basically 0% on any real-world program).
msg163498 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-06-22 21:59
> Are there any circumstances where this produces a larger speedup?

I don't know. *_find_max_char in any case only a part of expensive
functions. Even if it is optimized to zero time, this will most likely
not produce a larger speedup.

> I don't think a 10% improvement on a micro-benchmark is interesting at all (it's basically 0% on any real-world program).

I agree. It is rather a question of purity. In my opinion the function
has become easier (for developer and for compiler).
msg173176 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-10-17 13:56
Patch updated to tip.

But because results are contradictory and often patched version even slower vanilla (and I don't understand why it happens), I close the issue. I think all changes are irrelevant and differences are only compiler optimization artifacts.
msg173177 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-10-17 13:57
Thanks for the effort, Serhiy!
History
Date User Action Args
2022-04-11 14:57:31adminsetgithub: 59350
2012-10-17 13:57:54pitrousetmessages: + msg173177
2012-10-17 13:56:30serhiy.storchakasetstatus: open -> closed
files: + find_max_char_2.patch
messages: + msg173176

resolution: rejected
stage: patch review -> resolved
2012-10-17 13:49:21serhiy.storchakasetfiles: - find_max_char.patch
2012-06-29 00:04:48pitrousetversions: + Python 3.4, - Python 3.3
2012-06-23 15:01:12pitrousetnosy: + vstinner
2012-06-22 22:03:06pitrousetpriority: normal -> low
stage: patch review
2012-06-22 21:59:38serhiy.storchakasetmessages: + msg163498
2012-06-22 21:18:15pitrousetnosy: + pitrou
messages: + msg163489
2012-06-22 20:51:57serhiy.storchakacreate