Sorry, something went wrong.
|
Is iteration over sets common enough to justify this? Our main motivation for specializing FOR_ITER is to allow us to iterate over generators without making C calls and without slowing down iterating over sequences. |
Sorry, something went wrong.
|
@markshannon I am okay not applying this change if this is not worth specializing in the operation. |
Sorry, something went wrong.
| static PyObject *setiter_iternext(_PySetIterObject *si) { | ||
| PyObject *stack[1]; | ||
| int err = _PySetIter_GetNext(si, stack); | ||
| if (err <= 0) { | ||
| return NULL; | ||
| } | ||
| return stack[0]; | ||
| } |
There was a problem hiding this comment.
| static PyObject *setiter_iternext(_PySetIterObject *si) { | |
| PyObject *stack[1]; | |
| int err = _PySetIter_GetNext(si, stack); | |
| if (err <= 0) { | |
| return NULL; | |
| } | |
| return stack[0]; | |
| } | |
| static PyObject *setiter_iternext(_PySetIterObject *si) { | |
| PyObject *key; | |
| if (_PySetIter_GetNext(si, &key) <= 0) { | |
| return NULL; | |
| } | |
| return key; | |
| } |
might be better
Sorry, something went wrong.
|
Performance shows a 1% speedup, although I think this just shows that 1% variations can be caused by code layout changes and other build effects. Projecting from stats, FOR_ITER_SET would represent about 0.03% of executed instructions. (FOR_ITER_ADAPTIVE is 0.8% and of that only 4% are sets.) I doubt that any further specialization of FOR_ITER is worthwhile. |
Sorry, something went wrong.
|
@markshannon agree Let's close the PR! |
Sorry, something went wrong.
Microbenchmark
result: Mean +- std dev: [base] 662 ns +- 5 ns -> [FOR_ITER_SET] 616 ns +- 2 ns: 1.07x faster
Leak test
I just follow @sweeneyde's work.
(Following the faster CPython project is kind of my daily hobby ;) Sorry if you already worked on your local branch.. )
According to his stat, set iteration (3.8%) would be worth optimizing as same as tuple iteration (2.8%)
This PR would be decided to be merged after #94096 is merged.