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
Refs #34118 -- Avoided repeat coroutine checks in MiddlewareMixin. #17402
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this seems totally reasonable to me.
(The asgiref.sync
utilities include a check that they're correctly passed a coroutine marked class, so an error here would show in the test output, I trust.)
4145a57
to
e2922b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamchainz Thanks 👍
Thanks! Look after the microseconds and the milliseconds will look after themselves 😉 |
@felixxm backport so 5.0 doesn't have the performance regression? |
I categorized this as a cleanup. If we want to treat this as a bug it should be a release blocker for Django 4.2, so a separate ticket and a release note in |
Oh sorry, I didn't realize that commit was in 4.2, I thought it was only on the 5.0 branch. Eh, I can't be bothered filing a ticket if no one else has spotted this. |
(I don't think it's release blocker status...) |
32d70b2 changed
MiddlewareMixin
to calliscoroutinefunction
on every request. Whilst fast, it’s not free, with many function calls and unwrapping in its tree: https://github.com/python/cpython/blob/88bac5d5044e577825db1f9367af908dc9a3ad82/Lib/inspect.py#L420 . Multiplying this by many middlewares it will add up.This PR changes to cache the result in an instance variable, as it did before.
Quick benchmark shows
iscoroutinefunction
can take ~0.5us on a function with one decorator: