[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Yury Selivanov added the comment: IMO this particular patch is OK and should go in. I'll take another look at the PR in a few days (and will run some benchmarks myself before making the decision). -- ___ Python tracker

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

STINNER Victor added the comment: I disagree with your rationale. At least, it is not how we decide to optimize something or not in Python. Python is first made of people who will have to maintain the code for the next 5 years if not longer. C code is harder to maintain than Python code. A sign

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Jimmy Lai added the comment: @vstinner In general, we would like to make all asyncio common functions efficient with C implementation because CPython asyncio overhead is very expensive. In our application, overall it costs about 10% global CPU instructions after we used UVLoop (it's much worse

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

STINNER Victor added the comment: > @pitrou We'll measure the wins of gather when we implement it in C. Before > that, we need to get all helpers ready in C. You don't have to provide _asyncio.isfuture() (in C) to implement gather() in C. If your goal is to optimize gather(), write a change t

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Jimmy Lai added the comment: @pitrou We'll measure the wins of gather when we implement it in C. Before that, we need to get all helpers ready in C. -- ___ Python tracker ___

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Antoine Pitrou added the comment: Then it would be nice to post benchmarks using asyncio.gather() (on something not too trivial perhaps). -- ___ Python tracker ___ ___

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Jimmy Lai added the comment: @pitrou This change is part of optimization for asyncio.gather(). gather -> ensure_future -> isfuture/iscoroutine/isawaitable We need C implementation for all those function to make gather really efficient for large scale application (e.g. Instagram) Gather is real

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Antoine Pitrou added the comment: What is the impact on a regular application? The fact that a micro-benchmark becomes X% faster isn't very interesting itself, especially as the original function, at less than 1µs per call, is already very fast. -- nosy: +pitrou

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Jimmy Lai added the comment: @vstinner Thanks for the new benchmark, it provides more detailed wins: It's 1.64x faster for future object and 1.23x faster for non-future object. $ ./python.exe -m perf compare_to isfuture_original_2.json isfuture_optimized_2.json future: Mean +- std dev: [isfutur

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

STINNER Victor added the comment: About the benchmark: you should not loop inside the function. I propose a variant of the benchmark: isfuture_benchmark2.py. Jimmy: Would you mind to run this variant on your PR? -- Added file: https://bugs.python.org/file47603/isfuture_benchmark2.py

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Change by STINNER Victor : -- nosy: +vstinner versions: -Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Change by Jimmy Lai : -- keywords: +patch pull_requests: +6552 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list ma

[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().

Jimmy Lai added the comment: $./python.exe isfuture_benchmark.py -o isfuture_optimized.json $ ./python.exe -m perf compare_to isfuture_original.json isfuture_optimized.json Mean +- std dev: [isfuture_original] 7.16 ms +- 0.23 ms -> [isfuture_optimized] 5.41 ms +- 0.25 ms: 1.32x faster (-24%) -