Error page can sometimes be very slow

[Anders Hovmöller]

I hit a case in development today where the error page took over 20 seconds to render. After a bit of digging it happened for a few reasons:

• fairly deep call chain (20)
• the same arguments being passed down many levels
• those arguments contained querysets
• the querysets had reprs that accessed a related object

These things in combination resulted in almost 5000 database accesses.

I have a patch for this that can avoid this. It's pretty simple as the debug pretty printer goes through the entire stack in one for loop so it's easy to cache the sub-results.

[Carlton Gibson]

Hi Anders. Thanks for the report.

Slowness here is a symptom of chained ORM lookups, rather than the exception reporter per se. It's not something that we'd want to mask in general, because you want to notice it, so you can optimize your application.

If you do want to apply it yourself, your suggestion is the perfect case for the ​DEFAULT_EXCEPTION_REPORTER setting introduced in Django 3.1. Apply your cached pretty printer in a subclass and use it in your project.

I hope that makes sense.

[Anders Hovmöller]

I disagree. Optimizing queries with prefetch or select related can be done later. You are saying that we should always apply optimizations first just in case a debug page is hit.

In any case, if you don't like the fix, would you be open to a change that would break apart the big function my PR modifies so that this change can be implemented locally without copy pasting that big function (risking compatibility problems, missed bug fixes etc)?