Message286315
While they are obvious speedup on microbenchmarks, it doesn't speedup "macro" benchmarks from performance as much as I expected.
The changes required in typeobject.c to support "tp_new or tp_fastnew" and "tp_init or tp_fastinit" are large and very complex. I'm not sure that my code is correct. update_one_slot(), add_operators() and PyType_Ready() functions are complex beast, sadly almost not documented, except such comment...
/* The __new__ wrapper is not a wrapper descriptor,
so must be special-cased differently.
If we don't do this, creating an instance will
always use slot_tp_new which will look up
__new__ in the MRO which will call tp_new_wrapper
which will look through the base classes looking
for a static base and call its tp_new (usually
PyType_GenericNew), after performing various
sanity checks and constructing a new argument
list. Cut all that nonsense short -- this speeds
up instance creation tremendously. */
specific = (void *)type->tp_new;
/* XXX I'm not 100% sure that there isn't a hole
in this reasoning that requires additional
sanity checks. I'll buy the first person to
point out a bug in this reasoning a beer. */
How am I supposed to be confident in front of such coment :-D
I expect that calling a functions (tp_call) is a more common operation than instanciating a new object (tp_new + tp_init). So I don't think that the overall change is worth it.
For all these reaons, I close the issue as REJECTED. |
|
Date |
User |
Action |
Args |
2017-01-26 14:14:22 | vstinner | set | recipients:
+ vstinner, rhettinger, methane, python-dev, serhiy.storchaka, yselivanov, josh.r |
2017-01-26 14:14:22 | vstinner | set | messageid: <1485440062.7.0.21095046098.issue29358@psf.upfronthosting.co.za> |
2017-01-26 14:14:22 | vstinner | link | issue29358 messages |
2017-01-26 14:14:22 | vstinner | create | |
|