I just wanna point out one thing - not all N+1s are bad, the vast majority are and having a tool to help to see them is great, but there is a set of circumstances that if all met at the same time an N+1 is desirable:
You’re doing russian doll caching.
Your data is not too volatile (doesn’t change super frequently).
A reasonable amount of users can benefit from the same cached content.
Under these circumstances you actually benefit from the N+1.
The first request "pays the price" but the subsequent avoid the extra query.
These don't happen super often, but they exist and should be considered.
These often compensate when you have not just one N+1 but 2 or 3 of them stemming from the same initial query.
In any case, when in doubt... better to not have N+1s!
This makes a lot of sense. So the question for the developer here is whether to refactor the queries or add a cache. And because it's primarily a performance question, the answer will presumably be: it depends :-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This looks super cool and VERY VERY helpful.
I just wanna point out one thing - not all N+1s are bad, the vast majority are and having a tool to help to see them is great, but there is a set of circumstances that if all met at the same time an N+1 is desirable:
Under these circumstances you actually benefit from the N+1.
The first request "pays the price" but the subsequent avoid the extra query.
These don't happen super often, but they exist and should be considered.
These often compensate when you have not just one N+1 but 2 or 3 of them stemming from the same initial query.
In any case, when in doubt... better to not have N+1s!
This makes a lot of sense. So the question for the developer here is whether to refactor the queries or add a cache. And because it's primarily a performance question, the answer will presumably be: it depends :-)