[proxy] github.com← back | site home | direct (HTTPS) ↗ | proxy home | ◑ dark◐ light
/ cpython Public

Conversation

Copy link
Member

1st1 commented Jan 23, 2018

Microbenchmark I used:

import asyncio
import time


async def main():
    g = asyncio.get_running_loop
    t = time.monotonic()
    for _ in range(10**6):
        g(); g(); g(); g(); g(); g(); g(); g()
        g(); g(); g(); g(); g(); g(); g(); g()
        g(); g(); g(); g(); g(); g(); g(); g()
        g(); g(); g(); g(); g(); g(); g(); g()
    print(f'total: {time.monotonic() - t:.3f}s')


asyncio.run(main())

https://bugs.python.org/issue32296

Copy link
Contributor

njsmith commented Jan 23, 2018

I take it you concluded that this was easier than fixing run_until_complete to work with storing the running loop in a ContextVar?

Copy link
Member Author

1st1 commented Jan 23, 2018

I take it you concluded that this was easier than fixing run_until_complete to work with storing the running loop in a ContextVar?

I honestly have no idea how to do that with contextvars. This PR speeds things up because of:

  1. caching (similar to contextvars)
  2. avoiding boxing of integers and calling os.getpid(); getpid() is called directly.

80% of the speedup is (2).

static PyObject* future_new_iter(PyObject *);
static inline int future_call_schedule_callbacks(FutureObj *);

static PyRunningLoopHolder *
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The declaration fits into single line I think. A space between PyRunningLoopHolder and * is not needed.

1st1 merged commit 9d411c1 into python:master Jan 23, 2018
1st1 deleted the speedup_getrunning branch January 23, 2018 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants