Provide C implementation for asyncio.current_task

Feature or enhancement

By providing a C implementation for asyncio.current_task, its performance can be improved.

Pitch

Performance improvement.

From Instagram profiling data, we've found that this function is called frequently, and a C implementation (in Cinder 3.8) showed more than 4x speedup in a microbenchmark.

Previous discussion

N/A

Linked PRs

gh-100344: Provide C implementation for asyncio.current_task #100345

pythongh-100344: Provide C implementation for asyncio.current_task

Can you post benchmarks with pyperf?

Can you post benchmarks with pyperf?

You mean pyperformance suite with and without the C acceleration?

You mean pyperformance suite with and without the C acceleration?

No this microbenchmark with pyperf.

As a note of support for making this faster, current_task is used in the asgiref.local implementation, which is used a lot by Django, and it shows up in profiles.

No this microbenchmark with pyperf.

thanks for the clarification :)

I don't know how to isolate the overhead of the event loop when using pyperf, so hope this is helpful:

C implementation:

$ python -m pyperf timeit -s 'from asyncio.tasks import _c_current_task as current_task' -s 'from asyncio import run' -s '
async def main():
  for _ in range(10**6):
    current_task()
' 'run(main())'
.....................
Mean +- std dev: 33.4 ms +- 1.0 ms

Python implementation:

$ python -m pyperf timeit -s 'from asyncio.tasks import _py_current_task as current_task' -s 'from asyncio import run' -s '
async def main():
  for _ in range(10**6):
    current_task()
' 'run(main())'
.....................
Mean +- std dev: 133 ms +- 8 ms

@markshannon

The numbers looks interesting, it seems to be because there is no fastpath for dict.get like there is for list.append in ceval.

@markshannon Do you have plans to optimize this?

@kumaraditya303

@kumaraditya303 No plans at the moment.

I'd be interested to see how this compared:

def current_task(loop=None):
    """Return a currently executed task."""
    if loop is None:
        loop = events.get_running_loop()
    try:
        return _current_tasks[loop]
    except:
        return None

I assume that current_task() is expected to return a task, not None, most of the time.

I assume that current_task() is expected to return a task, not None, most of the time.

makes sense!

this optimization make the python impl about 40% faster!

$ python -m pyperf timeit -s 'from asyncio.tasks import _py_current_task as current_task' -s 'from asyncio import run' -s '
async def main():
  for _ in range(10**6):
    current_task()
' 'run(main())'
.....................
Mean +- std dev: 81.1 ms +- 4.9 ms

the C impl is still more than 2x faster than this, so maybe do both?

Why bother speeding up the Python version if we have the C version? There really aren't any interesting situations where the C accelerator is unavailable (that I know of).

Why bother speeding up the Python version if we have the C version? There really aren't any interesting situations where the C accelerator is unavailable (that I know of).

In my mind it's "why not speed up the Python version?"
I'm not aware of situations where it matters for cpython users, but maybe alternative implementations that use cpython's stdlib it would be valuable?
anyway, I don't feel strongly about it. happy to revert to the existing python implementation if you'd prefer!

In my mind it's "why not speed up the Python version?"

Because you're replacing one line of code with a well-known idiom with four lines of code that require the reader to follow carefully what's going on and why. For me, reading the version with .get() is much quicker than the try/except version.

If we wrote hyper-optimized code like that everywhere, even when speed doesn't matter, we'd end up with considerably less readable code. So, in my mind the question very much needs to be "why speed it up".

The optimization in the Python version is also very much tuned for the current performance characteristics of the adaptive interpreter (i.e. that dict subscripts are much better optimized than dict method calls.) If alternate Python implementations are the only likely users of the Python implementation, this code change won't necessarily give similar speedups for them.

gh-100344: Add C implementation for `asyncio.current_task` (#100345)

Backport gh-100345 / Port D39555934: Provide C implementation for asy…

Merged main into regmachine branch (#50)

Navigation Menu

Repository navigation

Provide C implementation for asyncio.current_task #100344

Feature or enhancement

Pitch

Previous discussion

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Provide C implementation for asyncio.current_task #100344

Description

Feature or enhancement

Pitch

Previous discussion

Linked PRs

Activity

kumaraditya303 commented on Dec 19, 2022

itamaro commented on Dec 19, 2022

kumaraditya303 commented on Dec 19, 2022

bluetech commented on Dec 19, 2022

itamaro commented on Dec 19, 2022

kumaraditya303 commented on Dec 20, 2022

markshannon commented on Dec 20, 2022

itamaro commented on Dec 20, 2022

gvanrossum commented on Dec 21, 2022

itamaro commented on Dec 21, 2022

gvanrossum commented on Dec 21, 2022

carljm commented on Dec 22, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions