Skip to content

bpo-31336: Speed up type creation, which is highly dominated by slow dict lookups. #3279

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
serhiy-storchaka merged 20 commits into from
Oct 1, 2017
Merged

bpo-31336: Speed up type creation, which is highly dominated by slow dict lookups. #3279

Changes from 1 commit
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
0a865c9
Speed up type creation, which is highly dominated by slow dict lookups.
Sep 4, 2017
c4779e3
Update comment after changing the function call that it refers to.
Sep 4, 2017
ff2ea63
Ignore any errors (however unlikely) that may happen during the mro c…
Sep 4, 2017
76b1986
Extract non-caching code from _PyType_Lookup() to use it directly fro…
Sep 5, 2017
6f98485
Avoid some useless overhead for the no-basetype case. If "object" eve…
Sep 5, 2017
d9b726e
Add comment.
Sep 6, 2017
be15255
Avoid uselessly searching empty bases for a metaclass. This is quite …
Sep 6, 2017
0736226
Avoid unsafe handling of borrowed "mro" reference during hash() call.
Sep 10, 2017
8bc783f
Clean up code and formatting a little.
Sep 10, 2017
66648dd
Add braces for code style reasons.
Sep 10, 2017
85fb3ae
Give internal helper function a local name that does not resemble (ex…
Sep 10, 2017
09e716a
Allow non-dict types for the class dict when looking up names and cal…
Sep 11, 2017
1d52082
Lazily calculate name hash in find_name_in_mro() to avoid potential r…
Sep 11, 2017
f09bfd3
Revert "Lazily calculate name hash in find_name_in_mro() to avoid pot…
Sep 11, 2017
824d7cb
Revert "Allow non-dict types for the class dict when looking up names…
Sep 11, 2017
5184191
add news entry for faster class creation
Sep 13, 2017
4efde8e
Change nice interface of "find_name_in_mro()" to evil interface eatin…
Sep 13, 2017
f5bce2a
Mention amount of speedup in News entry.
Sep 13, 2017
02bfef0
Revert "Change nice interface of "find_name_in_mro()" to evil interfa…
Sep 14, 2017
2497858
Guard against external live exceptions when calling find_name_in_mro(…
Sep 14, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add braces for code style reasons.
  • Loading branch information
Stefan Behnel
Stefan Behnel committed Sep 10, 2017
commit 66648dd568cfefdf1f003bce8fc2aced4ec6972b
3 changes: 2 additions & 1 deletion Objects/typeobject.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3037,8 +3037,9 @@ _PyType_Lookup(PyTypeObject *type, PyObject *name)
the same type will call it again -- hopefully
in a context that propagates the exception out.
*/
if (error == -1)
if (error == -1) {
PyErr_Clear();

@serhiy-storchaka serhiy-storchaka Sep 10, 2017

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PyErr_Clear() always is called after _PyType_LookupUncached() if error == -1. Why not call it inside _PyType_LookupUncached()?

@scoder scoder Sep 10, 2017

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The question is which interface is better: should the function itself always swallow any exceptions, or should the callers decide how to deal with them? The comments in the original _PyType_Lookup() implementation suggest that others have already been as unhappy as me about the interface of that function, so why keep making people unhappy?

}
return NULL;
}

Expand Down