[Python-Dev] file.readinto performance regression in Python 3.2 vs. 2.7?
Amaury Forgeot d'Arc
amauryfa at gmail.com
Fri Nov 25 16:07:59 CET 2011
More information about the Python-Dev mailing list
Fri Nov 25 16:07:59 CET 2011
- Previous message: [Python-Dev] file.readinto performance regression in Python 3.2 vs. 2.7?
- Next message: [Python-Dev] file.readinto performance regression in Python 3.2 vs. 2.7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2011/11/25 Paul Moore <p.f.moore at gmail.com> > The optimisation mentioned was an attempt (by mutating an existing > string when the runtime determined that it was safe to do so) to hide > the consequences of this fact from end-users who didn't fully > understand the issues. It was relatively effective, but like any such > case (floating point is another common example) it did some level of > harm at the same time as it helped (by obscuring the issue further). > > It would be nice to have the optimisation back if it's easy enough to > do so, for quick-and-dirty code, but it is not a good idea to rely on > it (and it's especially unwise to base benchmarks on it working :-)) > Note that this string optimization hack is still present in Python 3, but it now acts on *unicode* strings, not bytes. -- Amaury Forgeot d'Arc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20111125/40b9d293/attachment-0001.html>
- Previous message: [Python-Dev] file.readinto performance regression in Python 3.2 vs. 2.7?
- Next message: [Python-Dev] file.readinto performance regression in Python 3.2 vs. 2.7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list