diff options
author | Guido van Rossum <guido@python.org> | 2020-08-02 15:51:54 -0700 |
---|---|---|
committer | Guido van Rossum <guido@python.org> | 2020-08-02 15:51:54 -0700 |
commit | 66850f6f4e22e8652910311de68fe8b023dedcfc (patch) | |
tree | b991c9dd3b3bec0425163a5db4a2814ab2bd258d /Objects/descrobject.c | |
parent | ab72fdeb82c3ab045b480cd4bb4f928c12653ecb (diff) | |
download | cpython-git-faster-bytes-iter.tar.gz |
A (very) slight speed improvement for iterating over bytesfaster-bytes-iter
My mentee @xvxvxvxvxv noticed that iterating over array.array is
slightly faster than iterating over bytes. Looking at the source I
observed that arrayiter_next() calls `getitem(ao, it->index++)` wheras
striter_next() uses the idiom (paraphrased)
item = PyLong_FromLong(seq->ob_sval[it->it_index]);
if (item != NULL)
++it->it_next;
return item;
I'm not 100% sure but I think that the second version has fewer
opportunity for the CPU to overlap the `index++` operation with the
rest of the code (which in both cases involves a call). So here I am
optimistically incrementing the index -- if the PyLong_FromLong() call
fails, this will leave the iterator pointing at the next byte, but
honestly I doubt that anyone would seriously consider resuming use of
the iterator after that kind of failure (it would have to be a
MemoryError). And the author of arrayiter_next() made the same
consideration (or never ever gave it a thought :-).
With this, a loop like
for _ in b: pass
is now slightly *faster* than the same thing over an equivalent array,
rather than slightly *slower* (in both cases a few percent).
Diffstat (limited to 'Objects/descrobject.c')
0 files changed, 0 insertions, 0 deletions