-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
asyncio debug mode is very slow #76151
Comments
Each time a new future, handle or task is created, asyncio with debug mode enabled will parse the whole call stack and create a StackSummary object for it. Imagine a recursive coroutine: with N nested calls, you get O(N**2) performance. Ideally debug mode wouldn't slow things too much, at least for development and testing setups. |
If this is accepted on the principle, it would be great to also patch 3.6. |
Thank you for the quick reviews! |
Thank you for helping with asyncio! I'll try to get to that transport performance issues you found sometime this week. I've a few ideas how to add 0-copy support to protocols. |
I'd be interesting to hear about them. The main challenge IMHO is to find a way to allow a readinto()-like functionality. |
Exposing sendfile() should be straightforward. I started implementing it years ago but I gave up pretty soon because asyncio had no solid test framework for testing an actual data transfer between two sockets and that basically represented a blocker. Basically back then all recv() / send() related tests were mocks. Not sure about the current situation but if that has changed I would be happy to contribute a PR (I was the one who contributed socket.sendfile()). As for a readinto()-like functionality: the only thing I'm aware of is splice() syscall but it's Linux only. It must be noted that also sendfile() is UNIX only. Windows achieve the same via TransmitFile. |
Le 08/11/2017 à 14:40, Giampaolo Rodola' a écrit :
sendfile() is not useful for data that's read from (or written to) memory.
This is not the abstraction level we are talking about. The problem is |
Sorry. It looks like I completely misunderstood. =) |
IMHO performance is a good motivation to enhance the asyncio API ;-) The tricky part is to keep the backward compatibility. |
Let's stop the discussion in this ticket :) |
In any case, I think this is better discussed on async-sig (where I already started a discussion thread some weeks ago -- see """APIs for high-bandwidth large I/O?"""). |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: