get_event_loop() and _get_running_loop() can be faster.CaseTimeMeanImproveNo Change7.323 +- 0.1727.3230.00%Remove class _RunningLoop6.513 +- 0.1156.513-11.06%Expand _get_running_loop() inside get_event_loop()5.851 +- 0.1605.851-20.10%Use Tuple instead of two attributes6.179 +- 0.0996.179-15.62%Tuple + Remove _RunningLoop6.026 +- 0.1236.026-17.71%Tuple + return ternary + Remove _RunningLoop6.060 +- 0.1116.06-17.25%Combine all four optimizations4.735 +- 0.1114.735-35.34%Remove class _RunningLoop + Use Tuple instead of two attributes6.241 +- 0.0976.241-14.78%Experimenting with different techniques to optimize get_event_loop and _get_running_loop.After discuss with Yuri, decide not to expand _get_running_loop inside get_event_loop.Combine tuple in _running_loop and Remove _RunningLoop (just use threading.local) can achieve the best improvement: 17.71% faster.

Can you please provide the code of your benchmark?

Benchmark script: Run 10 times to get mean and stdevimport asyncioimport timeasync def async_get_loop():    start_time = time.time()    for _ in range(5000000):        asyncio.get_event_loop()    return time.time() - start_timeloop = asyncio.get_event_loop()results = []for _ in range(10):    start_time = time.time()    result = loop.run_until_complete(async_get_loop())    results.append(result)import statisticsprint("elapse time: %.3lf +- %.3lf secs" % (statistics.mean(results), statistics.stdev(results)))

I suggest to use my perf module to run benchmark, especially if the tested function takes less than 1 ms, which is the case here.Attached benchmark script calls asyncio.get_event_loop(). Result on the master branch withPR 3347:haypo@selma$ ./python ~/bench_asyncio.py --inherit=PYTHONPATH -o patch.jsonhaypo@selma$ ./python ~/bench_asyncio.py --inherit=PYTHONPATH -o ref.jsonhaypo@selma$ ./python -m perf compare_to ref.json patch.json Mean +- std dev: [ref] 881 ns +- 42 ns -> [patch] 859 ns +- 14 ns: 1.03x faster (-3%)I'm not convinced that the PR is worth it. 3% is not interesting on a micro benchmark.Or is there an issue in my benchmark?

> I'm not convinced that the PR is worth it. 3% is not interesting on a micro benchmark.I found a small issue in the PR (left a comment in the PR).I think using a tuple is still a good idea (even if the speedup is tiny) because logically, both attributes on that threading.local() object are always set and read at the same time.  Essentially, it's a pair of (loop, pid), so using a tuple here makes the code easier to reason about.

If the motivation is correctness and not performance, please adjust the issue and PR description :-)

> Or is there an issue in my benchmark?Yes.  The correct benchmark would be to measure `get_event_loop` performance from *within* a running event loop.

According to Jimmy, asyncio.get_event_loop() behaves differently if it's called while an event loop is running. So my first benchmark was wrong.Attached bench_get_event_loop.py measures asyncio.get_event_loop() performance when an event loop is running. I get a different result:haypo@selma$ ./python -m perf compare_to ref.json patch.json Mean +- std dev: [ref] 555 ns +- 11 ns -> [patch] 498 ns +- 11 ns: 1.11x faster (-10%)Ok, now it's 10% faster :-)

New changeset80bbe6a7b67f33d0d0976bb8e3e5ba26b6b0e626 by Yury Selivanov (jimmylai) in branch 'master':bpo-31350: Optimize get_event_loop and _get_running_loop (#3347)https://github.com/python/cpython/commit/80bbe6a7b67f33d0d0976bb8e3e5ba26b6b0e626

New changesetff125e1aa9ee4eb928de79320a0e7c1b0c0f58f4 by Mariatta (Miss Islington (bot)) in branch '3.6':bpo-31350: Optimize get_event_loop and _get_running_loop (GH-3347) (GH-3373)https://github.com/python/cpython/commit/ff125e1aa9ee4eb928de79320a0e7c1b0c0f58f4

This has been backported.Thanks all :)