Speedup types.coroutine() #68513

1st1 · 2015-05-29T16:23:27Z

BPO	24325
Nosy	@gvanrossum, @ncoghlan, @scoder, @vstinner, @larryhastings, @asvetlov, @markshannon, @vadmium, @1st1
Dependencies	bpo-24400: Awaitable ABC incompatible with functools.singledispatch
Files	types_coroutine_speedup.patch types_coroutine_speedup.patch types_coroutine_speedup.patch: more tests; rebase onto 24400; make GeneratorWrapper a GC type types_coroutine_speedup.patch: rebased; more tests types_coroutine_speedup.patch: new unittests have been committed; the patch now contains only the acceleration part

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/1st1'
closed_at = <Date 2018-01-29.20:10:43.091>
created_at = <Date 2015-05-29.16:23:27.316>
labels = ['type-feature', 'library']
title = 'Speedup types.coroutine()'
updated_at = <Date 2018-01-29.20:10:43.089>
user = 'https://github.com/1st1'

bugs.python.org fields:

activity = <Date 2018-01-29.20:10:43.089>
actor = 'yselivanov'
assignee = 'yselivanov'
closed = True
closed_date = <Date 2018-01-29.20:10:43.091>
closer = 'yselivanov'
components = ['Library (Lib)']
creation = <Date 2015-05-29.16:23:27.316>
creator = 'yselivanov'
dependencies = ['24400']
files = ['39547', '39563', '39754', '39774', '39803']
hgrepos = []
issue_num = 24325
keywords = ['patch']
message_count = 20.0
messages = ['244388', '244418', '244447', '244451', '244490', '244504', '245575', '245581', '245655', '245756', '245761', '245764', '246117', '246118', '246123', '246139', '246142', '246148', '246330', '311162']
nosy_count = 11.0
nosy_names = ['gvanrossum', 'ncoghlan', 'scoder', 'vstinner', 'larry', 'Arfrever', 'asvetlov', 'Mark.Shannon', 'python-dev', 'martin.panter', 'yselivanov']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24325'
versions = ['Python 3.5', 'Python 3.6']

1st1 · 2015-05-29T16:23:27Z

Attached patch provides an implementation (part of it) of types.coroutine in C.

The problem with the current pure Python implementation is that it copies the code object of the generator function, which is a small overhead during import.

I'm not sure if this should be merged in 3.5 at all. Please take a look at the patch.

1st1 · 2015-05-29T21:10:37Z

Attached is the second iteration of the patch. Now, besides just speeding up types.coroutine() for pure python generator functions, it also provides a better wrapper around generator-like objects.

larryhastings · 2015-05-30T06:09:02Z

This looks big and complicated. I'd prefer this skipped 3.5 and just went into 3.6.

scoder · 2015-05-30T07:23:56Z

I would still like to see a patch in Py3.5 that only flips the bit in C when "_types" is available and otherwise falls back to the existing Python code that creates a new code object. This part is much cleaner and faster to do in C than in the current Python implementation.

1st1 · 2015-05-30T20:22:26Z

Larry, can you accept the first version of the patch (only function that patches code object's co_flags) after beta2?

I'm OK if you think it should only be committed in 3.6, but I also agree with Stefan, that using C is better in this particular case.

gvanrossum · 2015-05-31T00:35:30Z

Since it's a speedup it could also go into 3.5.1.
On May 30, 2015 1:22 PM, "Yury Selivanov" <report@bugs.python.org> wrote:

Yury Selivanov added the comment:

Larry, can you accept the first version of the patch (only function that
patches code object's co_flags) after beta2?

I'm OK if you think it should only be committed in 3.6, but I also agree
with Stefan, that using C is better in this particular case.

----------

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue24325\>

1st1 · 2015-06-20T21:37:49Z

Larry, Nick,

Looking at how bpo-24400 progresses, I think it would be really great if we can merge this one in 3.5.0. It also makes it unnecessary to merge bpo-24468 in 3.5.

ncoghlan · 2015-06-21T01:59:05Z

+1 from me for merging this for 3.5.0 and deferring bpo-24468 (which now proposes making _opcode a builtin module to allow compiler constants to be easily shared between C code and Python code) to 3.6 instead.

The design changes to address bpo-24400 cleaned up various aspect of both the internal architecture and the public data model of PEP-492, and the latest draft of this patch benefits accordingly.

1st1 · 2015-06-22T22:09:36Z

A rebased version of the patch is attached (now a "review" link should appear).

Nick, Stefan, please take a look.

Larry, can we merge this in 3.5.0? I've invested a lot of time to have 100% test coverage; the test suite is very elaborate now. There seems to be no refleaks too. I think this change is a very natural continuation of what we've done in bpo-24400.

python-dev · 2015-06-24T15:45:34Z

New changeset eb6fb8e2f995 by Yury Selivanov in branch '3.5':
Issue bpo-24325, bpo-24400: Add more unittests for types.coroutine; tweak wrapper implementation.
https://hg.python.org/cpython/rev/eb6fb8e2f995

New changeset 7a2a79362bbe by Yury Selivanov in branch 'default':
Merge 3.5 (Issue bpo-24325, bpo-24400)
https://hg.python.org/cpython/rev/7a2a79362bbe

python-dev · 2015-06-24T16:52:04Z

New changeset 9aee273bf8b7 by Yury Selivanov in branch '3.5':
Issue bpo-24400, bpo-24325: More tests for types._GeneratorWrapper
https://hg.python.org/cpython/rev/9aee273bf8b7

New changeset fa097a336079 by Yury Selivanov in branch 'default':
Merge 3.5 (issue bpo-24325 & bpo-24400)
https://hg.python.org/cpython/rev/fa097a336079

1st1 · 2015-06-24T17:01:26Z

I've committed new unittests from this patch (as they are applicable to pure Python implementation of the wrapper too)

The patch now contains only the C implementation of the wrapper and should be ready to be committed. Larry?

larryhastings · 2015-07-03T01:01:09Z

Help me to understand here. You want to check in a patch adding 300 new lines of C code to the types module during beta, for a speed optimization, after we've already hit beta?

While I like speedups as much as the next guy, I would be happier if this waited for 3.6.

Of course, if Guido is overruling me, then Guido is overruling me and you get to check it in.

larryhastings · 2015-07-03T01:25:08Z

Oh, wait, I was confusing myself. This is that new module you guys created for type hints, and this is a new object with no installed base. (Right?)

Yeah, you can check it in for 3.5.

1st1 · 2015-07-03T03:56:34Z

Oh, wait, I was confusing myself. This is that new module you guys created for type hints, and this is a new object with no installed base. (Right?)

No, you were right in your previous comment...

Help me to understand here. You want to check in a patch adding 300 new lines of C code to the types module during beta, for a speed optimization, after we've already hit beta?

While I like speedups as much as the next guy, I would be happier if this waited for 3.6.

This speedup will mostly affect code compiled with Cython. See the following example:

@asyncio.coroutine
def coro():
yield from ...

Cython will compile "coro" into a function, that returns a generator-like object. "asyncio.coroutine" will wrap this function, and, therefore, the optimized by Cython generator-like object will be wrapped too (to provide an __await__ method).

This patch provides a faster wrapper for such generator-like objects. Since the whole point of using Cython is to squeeze as much performance as possible, I think it's essential to have this optimization in 3.5 (or at least in 3.5.1 as Guido suggested).

It's a lot of C code, I agree. I only can say that I did my best to write very extensive unittests, and so I hope that it won't cause any trouble.

scoder · 2015-07-03T06:23:22Z

This is not purely about speeding up the code. It's also about avoiding to replace the code object of a function, which is essentially a big and clumsy hack only to achieve setting a flag. Some tools, namely line_profiler, use the current code object as a dict key for state keeping. Replacing the reference in "__code__" might confuse them if they happened to catch a reference before.

That's why I asked for applying at least the simple patch that sets the flag with a C level helper function. But I'd be ok with applying the latest patch as it is. The non-flag-setting parts are simple and a straight forward translation of the current Python code.

markshannon · 2015-07-03T07:26:51Z

Does this have a measurable performance impact?
I'd be surprised if it did.

W.r.t. to profiling, the undecorated form will never be visible to any code other than the decorator, so won't show up in the profiler.

scoder · 2015-07-03T07:47:31Z

the undecorated form will never be visible to any code other than the decorator

Assuming that 1) it's the first and/or only decorator, 2) it's used to
decorate a generator function that returns its own generator and 3) it's
really used as a decorator and not as a general helper function to safely
wrap some object that was created somewhere else.

markshannon · 2015-07-05T18:41:43Z

If type.coroutine is not the first and only decorator, then things may be even worse.

Code objects are currently immutable.
This change would mean that a call to types.coroutine in one place in the code would change the semantics of another piece of code in a potentially surprising way.

I think creating a copy is probably the best thing to.

1st1 · 2018-01-29T20:10:43Z

Closing this one now--there's no point in speeding up types.coroutine anymore.

1st1 self-assigned this May 29, 2015

1st1 added the stdlib Python modules in the Lib dir label May 29, 2015

serhiy-storchaka added the type-feature A feature request or enhancement label May 30, 2015

1st1 closed this as completed Jan 29, 2018

ezio-melotti transferred this issue from another repository Apr 10, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Speedup types.coroutine() #68513

Speedup types.coroutine() #68513

1st1 commented May 29, 2015

1st1 commented May 29, 2015

1st1 commented May 29, 2015

larryhastings commented May 30, 2015

scoder commented May 30, 2015

1st1 commented May 30, 2015

gvanrossum commented May 31, 2015

1st1 commented Jun 20, 2015

ncoghlan commented Jun 21, 2015

1st1 commented Jun 22, 2015

python-dev mannequin commented Jun 24, 2015

python-dev mannequin commented Jun 24, 2015

1st1 commented Jun 24, 2015

larryhastings commented Jul 3, 2015

larryhastings commented Jul 3, 2015

1st1 commented Jul 3, 2015

scoder commented Jul 3, 2015

markshannon commented Jul 3, 2015

scoder commented Jul 3, 2015

markshannon commented Jul 5, 2015

1st1 commented Jan 29, 2018

Speedup types.coroutine() #68513

Speedup types.coroutine() #68513

Comments

1st1 commented May 29, 2015

1st1 commented May 29, 2015

1st1 commented May 29, 2015

larryhastings commented May 30, 2015

scoder commented May 30, 2015

1st1 commented May 30, 2015

gvanrossum commented May 31, 2015

1st1 commented Jun 20, 2015

ncoghlan commented Jun 21, 2015

1st1 commented Jun 22, 2015

python-dev mannequin commented Jun 24, 2015

python-dev mannequin commented Jun 24, 2015

1st1 commented Jun 24, 2015

larryhastings commented Jul 3, 2015

larryhastings commented Jul 3, 2015

1st1 commented Jul 3, 2015

scoder commented Jul 3, 2015

markshannon commented Jul 3, 2015

scoder commented Jul 3, 2015

markshannon commented Jul 5, 2015

1st1 commented Jan 29, 2018