| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
…s and plain Python objects. Work in progress.
|
🤖 New build scheduled with the buildbot fleet by @markshannon for commit 79e61bf 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @markshannon for commit ce0f65b 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
| # define _PyGC_FINALIZED(o) PyObject_GC_IsFinalized(o) | ||
| #endif | ||
|
|
||
| PyAPI_FUNC(PyObject *) _PyObject_GC_Malloc(size_t size); |
There was a problem hiding this comment.
_PyObject_GC_Malloc is part of stable ABI. AFAIK the function cannot be removed.
Sorry, something went wrong.
There was a problem hiding this comment.
It's not part of the stable ABI. It starts with an underscore.
https://www.python.org/dev/peps/pep-0384/#excluded-functions
Sorry, something went wrong.
There was a problem hiding this comment.
Misc/stable_abi.txt define it as stable ABI.
function _PyObject_GC_Malloc
added 3.2
abi_only
On the other hand, no public macro in Python/C API use it. So I doubt it is actually stable abi.
As far as this repo, only one package in top4000 packages uses it.
https://github.com/hpyproject/top4000-pypi-packages/search?q=_PyObject_GC_Malloc
Sorry, something went wrong.
There was a problem hiding this comment.
I sent an email to python-dev asking for clarification of the status of this functions and others that start with _ but are listed in Misc/stable_abi.txt. (It is not listed in Doc/data/stable_abi.dat.)
Sorry, something went wrong.
There was a problem hiding this comment.
Here's a first pass at a review, mostly nits. I think I'm following everything, though I'm not necessarily fully aware of the whole big picture.
Sorry, something went wrong.
| # define _PyGC_FINALIZED(o) PyObject_GC_IsFinalized(o) | ||
| #endif | ||
|
|
||
| PyAPI_FUNC(PyObject *) _PyObject_GC_Malloc(size_t size); |
There was a problem hiding this comment.
I sent an email to python-dev asking for clarification of the status of this functions and others that start with _ but are listed in Misc/stable_abi.txt. (It is not listed in Doc/data/stable_abi.dat.)
Sorry, something went wrong.
| _PyObject_GC_Link(PyObject *op) | ||
| { | ||
| PyGC_Head *g = AS_GC(op); | ||
| assert(((uintptr_t)g & (sizeof(uintptr_t)-1)) == 0); // g must be correctly aligned |
There was a problem hiding this comment.
Wow, you can use & on pointers. I didn't know that. :-)
Sorry, something went wrong.
There was a problem hiding this comment.
Only after you've cast it to an int. You can do anything with a cast 🙂
NULL is usually just 0 cast to a pointer, after all.
Sorry, something went wrong.
There was a problem hiding this comment.
Oh, somehow I thought uintptr_t was a pointer. :-/
Sorry, something went wrong.
| Py_TPFLAGS_MANAGED_DICT = (1 << 4) | ||
| Py_TPFLAGS_HEAPTYPE = (1 << 9) |
There was a problem hiding this comment.
Please realign these like the rest?
Sorry, something went wrong.
| else { | ||
| if (!PyDict_CheckExact(dict)) { |
There was a problem hiding this comment.
I'm guessing that if we have a class of objects and only some of those have a materialized __dict__ that will wreak havoc with our specialization, right? Because it will flop-flop as it encounters instances with and without __dict__. In this case we have to hope that the vast majority don't have a __dict__.
Sorry, something went wrong.
There was a problem hiding this comment.
Yes.
The specialized case is so much faster though, that it might not be any worse than not specializing at all, even in that case.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM.
Sorry, something went wrong.
python/cpython#29879 changed the layout of user classes, and the code is no longer able to find the location of __dict__. Do a quick fix for now, as we don't support pretty-printing user defined classes.
python/cpython#29879 changed the layout of user classes, and the code is no longer able to find the location of __dict__. Do a quick fix for now, as we don't support pretty-printing user defined classes.
| Back | FazBrowse Home | New Git URL |
Produces a solid 1% speedup
See faster-cpython/ideas#80 for full discussion.
https://bugs.python.org/issue45947