Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
On Mon, Aug 23, 2021 at 05:42:59PM +0000, Serhiy Storchaka wrote:
>
> Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
>
> Should getattr() normalize attribute name? If no, it will produce
> surprises further along the way. If yes, it will add significant
> overhead.
Good point.
In pure Python, normalising the string in getattr does have significant
cost, about 125% slower on my computer using 3.9:
>>> from functools import partial
>>> import unicodedata
>>> normalise = partial(unicodedata.normalize, "NFKC")
>>> def mygetattr(obj, name, _normalise=normalise, _getattr=getattr):
... return _getattr(obj, _normalise(name))
...
>>> t1 = Timer('getattr([], "reverse")')
>>> t2 = Timer('mygetattr([], "reverse")', setup='from __main__ import
mygetattr')
>>>
>>> min(t1.repeat(repeat=7))
0.08972279605222866
>>> min(t2.repeat(repeat=7))
0.20272555301198736
>>> (0.20272555301198736-0.08972279605222866)/0.08972279605222866
1.2594653971102117
But for ASCII strings at least, I think there is an opportunity to avoid
that cost entirely. See #44987.
> Even star-import can get significant impact.
I'm less worried about that for three reasons:
1. It only affects star-import, which is not "best practice", so only a
small number of scripts will be affected.
2. In the most overwhelming common case, you do any star-imports once,
at the beginning of the module, not repeatedly. Star-imports will not be
part of a tight, performance critical loop. So it is a one-off cost.
3. The cost of an import is a lot more than just the getattr, so any
normalisation cost is a correspondingly smaller part of the total.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue44981>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
