bpo-37337: Add _PyObject_CallMethodNoArgs() #14267
Conversation
d6fbe6e to
338f557
Compare
|
I suggest to avoid &self hack. I tried in the past, and it caused me troubles: https://bugs.python.org/issue28858#msg282377 I used such hack in a _PyObject_CallArg1() macro: "And I expected that the C compiler magically computes the memory address of the argument. But it seems like requesting the memory address of an argument allocates something on the C stack. On x86_64, first function arguments are passed with CPU registers. Maybe requesting the memory address of an argument requires to allocate a local variable, copy the register into the variable, to get the address of the local variable?" The fix was to remove the macro: https://hg.python.org/cpython/rev/4171cc26272c |
|
@vstinner But in your case, that was not a function argument; it was a macro. Here we have an (inline) function;
Is there something wrong with that? |
|
I suggest to measure the actual stack consumption. I don't trust compilers anymore ;-) |
I have a feeling that the problem was because you were using a macro. This would pass a pointer to some object inside the caller. This looks less safe than my version with a |
It wasn't a bug, but just that the macro increased the stack consumption. |
|
Code all seems fine, but I'm not enough of a C performance expert to do the final merge. |
Test code: from _testcapi import stack_pointer
class D(dict):
def items(self):
sp = stack_pointer()
print(f"stack used: {TOP - sp}")
return []
mappingproxy = type(object.__dict__)
p = mappingproxy(D())
TOP = stack_pointer()
p.items()Before: stack used: 912 So at least in this example, stack usage is reduced substantially. |
|
LGTM, except |
ed7d618 to
2b2da79
Compare
Of course, I just forgot that there were two different functions. Since you and Petr have a preference for |
CC @methane @vstinner
https://bugs.python.org/issue37337