Re: [Python-Dev] cpython: Use cached builtins.
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka <python-checkins@python.org> wrote:
http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user: Serhiy Storchaka <storchaka@gmail.com> date: Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins.
What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit. Regards Antoine.
On 10/2/13 1:31 PM, Antoine Pitrou wrote:
http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user: Serhiy Storchaka <storchaka@gmail.com> date: Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins. What's the point? I don't think it's a good idea to uglify the code if
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka <python-checkins@python.org> wrote: there isn't a clear benefit.
This type of micro-optimization seems especially unnecessary in a module intended for printing. --Ned.
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com
02.10.13 20:31, Antoine Pitrou написав(ла):
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka <python-checkins@python.org> wrote:
http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user: Serhiy Storchaka <storchaka@gmail.com> date: Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins.
What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit.
These builtins already were cached. I only change recently added code to use cached values. The point was perhaps that the access to module globals is a little faster than to builtins. Fred Drake was introduced this in changeset 261a70c0aa79. You can open a separate issue for removing this caching or for adding new builtins to this set.
I don't remember where, but I remember that I also saw things like "str=str, len=len, ...". So you keep the same name, but you use fast local lookups instead of slow builtin lookups. Victor 2013/10/2 Antoine Pitrou <solipsis@pitrou.net>:
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka <python-checkins@python.org> wrote:
http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user: Serhiy Storchaka <storchaka@gmail.com> date: Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins.
What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit.
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
Am 02.10.2013 21:58, schrieb Victor Stinner:
I don't remember where, but I remember that I also saw things like "str=str, len=len, ...". So you keep the same name, but you use fast local lookups instead of slow builtin lookups.
In this case they aren't even fast local lookups but (slightly) faster module global lookups. Not worth the effort IMO. Georg
On 3 Oct 2013 06:00, "Victor Stinner" <victor.stinner@gmail.com> wrote:
I don't remember where, but I remember that I also saw things like "str=str, len=len, ...". So you keep the same name, but you use fast local lookups instead of slow builtin lookups.
functools uses the local binding trick in lru_cache as a speed hack (pretty sure it uses an underscore prefix, though). However lru_cache *is* likely to end up being speed critical *and* it's binding local variables , so it's actually shifting a lot more work to compile time than merely trading a builtin lookup for a global lookup does. For most code though, introducing that kind of complexity isn't worth the cost in readability. Cheers, Nick.
Victor
2013/10/2 Antoine Pitrou <solipsis@pitrou.net>:
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka <python-checkins@python.org> wrote:
http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user: Serhiy Storchaka <storchaka@gmail.com> date: Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins.
What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit.
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
On 3 Oct 2013, at 12:05, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 3 Oct 2013 06:00, "Victor Stinner" <victor.stinner@gmail.com> wrote:
I don't remember where, but I remember that I also saw things like "str=str, len=len, ...". So you keep the same name, but you use fast local lookups instead of slow builtin lookups.
functools uses the local binding trick in lru_cache as a speed hack (pretty sure it uses an underscore prefix, though).
Inside a function you *have* to use an underscore prefix (well, some alternate name anyway) - otherwise the assignment makes the name local and the lookup would fail with an unbound local error. In order to do the binding at definition time rather than call time (so only once) the assignment is often done in the function signature. This is *particularly* ugly as it not only messes up the using of the builtins but screws your function signature too. So It should really only be done where benchmarking proves it makes a difference. I've never managed to find such a case... Michael
However lru_cache *is* likely to end up being speed critical *and* it's binding local variables , so it's actually shifting a lot more work to compile time than merely trading a builtin lookup for a global lookup does.
For most code though, introducing that kind of complexity isn't worth the cost in readability.
Cheers, Nick.
Victor
2013/10/2 Antoine Pitrou <solipsis@pitrou.net>:
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka <python-checkins@python.org> wrote:
http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user: Serhiy Storchaka <storchaka@gmail.com> date: Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins.
What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit.
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org....
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
participants (7)
-
Antoine Pitrou -
Georg Brandl -
Michael Foord -
Ned Batchelder -
Nick Coghlan -
Serhiy Storchaka -
Victor Stinner