<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/cpython-git.git/Objects, branch faster-bytes-iter</title>
<subtitle>github.com: python/cpython.git
</subtitle>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/'/>
<entry>
<title>A (very) slight speed improvement for iterating over bytes</title>
<updated>2020-08-02T22:51:54+00:00</updated>
<author>
<name>Guido van Rossum</name>
<email>guido@python.org</email>
</author>
<published>2020-08-02T22:51:54+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=66850f6f4e22e8652910311de68fe8b023dedcfc'/>
<id>66850f6f4e22e8652910311de68fe8b023dedcfc</id>
<content type='text'>
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-&gt;index++)` wheras
striter_next() uses the idiom (paraphrased)

    item = PyLong_FromLong(seq-&gt;ob_sval[it-&gt;it_index]);
    if (item != NULL)
        ++it-&gt;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).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;index++)` wheras
striter_next() uses the idiom (paraphrased)

    item = PyLong_FromLong(seq-&gt;ob_sval[it-&gt;it_index]);
    if (item != NULL)
        ++it-&gt;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).
</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-41342: Convert int.__round__ to Argument Clinic (GH-21549)</title>
<updated>2020-07-20T12:57:37+00:00</updated>
<author>
<name>Serhiy Storchaka</name>
<email>storchaka@gmail.com</email>
</author>
<published>2020-07-20T12:57:37+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=5a2bac7fe0e7a2b67fd57c7a9176a50feed0d7a0'/>
<id>5a2bac7fe0e7a2b67fd57c7a9176a50feed0d7a0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-41334: Convert constructors of str, bytes and bytearray to Argument Clinic (GH-21535)</title>
<updated>2020-07-20T12:53:55+00:00</updated>
<author>
<name>Serhiy Storchaka</name>
<email>storchaka@gmail.com</email>
</author>
<published>2020-07-20T12:53:55+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=12f433411bba8a0cdc4f09ba34472745ae9da0d1'/>
<id>12f433411bba8a0cdc4f09ba34472745ae9da0d1</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-41343: Convert methods of complex to Argument Clinic (GH-21550)</title>
<updated>2020-07-20T12:53:29+00:00</updated>
<author>
<name>Dong-hee Na</name>
<email>donghee.na92@gmail.com</email>
</author>
<published>2020-07-20T12:53:29+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=e123012d79121ab543583631bb84c7fc27d06338'/>
<id>e123012d79121ab543583631bb84c7fc27d06338</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-41333: Convert OrderedDict.pop() to Argument Clinic (GH-21534)</title>
<updated>2020-07-19T06:18:55+00:00</updated>
<author>
<name>Serhiy Storchaka</name>
<email>storchaka@gmail.com</email>
</author>
<published>2020-07-19T06:18:55+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=6bf3237379b17632db52cb39d181e8bac70173f3'/>
<id>6bf3237379b17632db52cb39d181e8bac70173f3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-41295: Reimplement the Carlo Verre "hackcheck" (GH-21528)</title>
<updated>2020-07-18T21:19:50+00:00</updated>
<author>
<name>scoder</name>
<email>stefan_ml@behnel.de</email>
</author>
<published>2020-07-18T21:19:50+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=c53b310e5926266ce267c44a168165cacd786d6e'/>
<id>c53b310e5926266ce267c44a168165cacd786d6e</id>
<content type='text'>
Walk down the MRO backwards to find the type that originally defined the final `tp_setattro`, then make sure we are not jumping over intermediate C-level bases with the Python-level call.

Automerge-Triggered-By: @gvanrossum</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Walk down the MRO backwards to find the type that originally defined the final `tp_setattro`, then make sure we are not jumping over intermediate C-level bases with the Python-level call.

Automerge-Triggered-By: @gvanrossum</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-41262: Convert memoryview to Argument Clinic. (GH-21421)</title>
<updated>2020-07-18T08:12:05+00:00</updated>
<author>
<name>Serhiy Storchaka</name>
<email>storchaka@gmail.com</email>
</author>
<published>2020-07-18T08:12:05+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=80a50368c0e4dc9d56af0ce748dea35c9d96d23f'/>
<id>80a50368c0e4dc9d56af0ce748dea35c9d96d23f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix a small grammatical mistake in a comment (GH-21526)</title>
<updated>2020-07-17T20:09:21+00:00</updated>
<author>
<name>Brett Cannon</name>
<email>brett@python.org</email>
</author>
<published>2020-07-17T20:09:21+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=d583738a87c3019dcfe06ed4a0002d1d6c9e9762'/>
<id>d583738a87c3019dcfe06ed4a0002d1d6c9e9762</id>
<content type='text'>
Automerge-Triggered-By: @brettcannon</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Automerge-Triggered-By: @brettcannon</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-40941: Unify implicit and explicit state in the frame and generator objects into a single value. (GH-20803)</title>
<updated>2020-07-17T10:44:23+00:00</updated>
<author>
<name>Mark Shannon</name>
<email>mark@hotpy.org</email>
</author>
<published>2020-07-17T10:44:23+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=cb9879b948a19c9434316f8ab6aba9c4601a8173'/>
<id>cb9879b948a19c9434316f8ab6aba9c4601a8173</id>
<content type='text'>
* Merge gen and frame state variables into one.

* Replace stack pointer with depth in PyFrameObject. Makes code easier to read and saves a word of memory.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Merge gen and frame state variables into one.

* Replace stack pointer with depth in PyFrameObject. Makes code easier to read and saves a word of memory.</pre>
</div>
</content>
</entry>
<entry>
<title>bpo-36346: Make using the legacy Unicode C API optional (GH-21437)</title>
<updated>2020-07-10T20:26:06+00:00</updated>
<author>
<name>Serhiy Storchaka</name>
<email>storchaka@gmail.com</email>
</author>
<published>2020-07-10T20:26:06+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/cpython-git.git/commit/?id=4c8f09d7cef8c7aa07d5b5232b5b64f63819a743'/>
<id>4c8f09d7cef8c7aa07d5b5232b5b64f63819a743</id>
<content type='text'>
Add compile time option USE_UNICODE_WCHAR_CACHE. Setting it to 0
makes the interpreter not using the wchar_t cache and the legacy Unicode C API.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add compile time option USE_UNICODE_WCHAR_CACHE. Setting it to 0
makes the interpreter not using the wchar_t cache and the legacy Unicode C API.</pre>
</div>
</content>
</entry>
</feed>
