[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Change by Inada Naoki : -- nosy: +inada.naoki ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Marco Sulla added the comment: I asked why on StackOverflow, and an user seemed to find the reason. The problem for him/her is in `update_one_slot()`. `dict` implements directly `__contains__()` and `__getitem__()`. Usually, `sq_contains` and `mp_subscript` are wrapped to implement

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Raymond Hettinger added the comment: Some thoughs: * Lib/sets.py benefitted significantly from itertools and METH_COEXIST. * The dunder methods are part of the public API. Serhiy's persona tastes aside, there is no reason not to use them like any other method. * Given a performance

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14652 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14863 ___ Python tracker ___

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Jeroen Demeyer added the comment: OK, makes sense. Also super() calls I guess: you can write super().__getitem__(x) but not super()[x] (although the latter *could* be implemented if we wanted to). I see two ways of fixing this: 1. Make wrapper descriptors faster, removing the need for the

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Serhiy Storchaka added the comment: > But what's the use case of making somedict.__getitem__(x) fast? One should > just write somedict[x] instead. Using them in itertools functions. somedict.__getitem__ is faster that lambda: somedict[x]. As for map() and filter(), comprehensions are

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Change by Stefan Behnel : -- nosy: +scoder ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Jeroen Demeyer added the comment: > Amusingly, this is because of an old hack to make directly calling > somedict.__getitem__ fast: > https://github.com/python/cpython/commit/8f5cdaa784f555149adf5e94fd2e989f99d6b1db But what's the use case of making somedict.__getitem__(x) fast? One should

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Change by Raymond Hettinger : -- nosy: +rhettinger versions: -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Dan Snider added the comment: Well, I found another mystery. Calling tuple.__getitem__ directly, on an actual tuple instance, is 50-80% slower than calling list.__getitem__ even though in theory, they should be virtually identical with maybe tuple access being infinitesimally be faster.

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

Benjamin Peterson added the comment: Amusingly, this is because of an old hack to make directly calling somedict.__getitem__ fast: https://github.com/python/cpython/commit/8f5cdaa784f555149adf5e94fd2e989f99d6b1db Reverting the dictobject.c changes of the commit, i.e., the following patch,

[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty

New submission from Dan Snider : The ones I know of are list.__getitem__, dict __contains__ & __getitem__, and (frozen)set.__contains__ but from what I can tell so far it seems like dict.__getitem__ takes the worst hit. For dicts, I've spent a few hours trying to figure out what's getting