Opened 9 months ago
Closed 9 months ago
#35229 closed Cleanup/optimization (fixed)
Prevent repeated checks of custom error handler URLs
Reported by: | Adam Johnson | Owned by: | Adam Johnson |
---|---|---|---|
Component: | Core (System checks) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In #29642 I added a system check for custom error handler URLs.
I looked at a profile for running the system checks on a project and found this check function ran hundreds of times rather than once, totalling 1/4 of the time to run checks. The multiple runs occur because the check is defined on URLResolver
, of which exist in a tree structure. Moving the check from URLResolver
to a function in django.core.checks.urls
ensures it runs only once.
In the profiled project with 279 URLs, this takes the checks from ~24ms to ~21ms, a ~13% saving.
Change History (4)
comment:1 by , 9 months ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 9 months ago
It would be nice, but it’s very hard. Many of the performance problems will only appear with scale, with many related models, URLs, etc. I think, for now, it’s more fruitful to profile running checks on real projects.
By the way, this burst of optimization tickets is inspired by a Mastodon discussion about disabling checks because of their slowness: https://mastodon.social/@webology/111715052165307624 . I decided to profile a client project yesterday and work on the clear hot spots.
comment:3 by , 9 months ago
Owner: | changed from | to
---|---|
Triage Stage: | Accepted → Ready for checkin |
Do you think it might be worth adding a check running benchmark as well?