Closed hatkirby closed 6 years ago
Assuming the worst case of all trainers having a full party and full boxes, we can estimate that before this commit, the front page was running ~852 queries per trainer. After the commit, it appears to be running ~45 queries per trainer, which is significantly better, but still needs to be better. The current page also still loads redundant data (querying for the same species repeatedly if they can be found in separate boxes) and unnecessary data (Pokémon revisions other than just the last one). The next step should probably be to move the query construction from the model into the controller.
Before the last commit, the front page took 2 queries to load. It now takes 2 queries, plus an extra query for every Unown, and an extra two queries for every Deoxys. While this is not ideal, it is unlikely to be a huge issue, but efforts to reducing this can be made later. Additionally, the main query now takes a little bit longer because it loads every column of Pokemon and Revision instead of just the necessary ones.
The front page executes at least two SQL queries for every Pokémon, and thus is really slow. It would benefit a lot from eager loading, but the current schema doesn't allow for that very easily. An alternate schema where the Box table is replaced by a Storage table (which is mostly the same but also allows for containing a party instead of just a box) may prove more useful, because then we can query for a Trainer and eager load Storage, through which we load Pokemon, and through which we load Revision.