-
Notifications
You must be signed in to change notification settings - Fork 274
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
[Performance] Get weight sum along with bills to scale #949
Conversation
Please review and test. I feel like I did some SQLAlchemy magic without fully understanding what I did. But normally, all bills are here with much less queries. |
I integrated it on my own instance (Intel Atom D2550), and I dropped from 6,2s to 1,5s page loading in a budget with 197 bills. |
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.
The principle looks good and the generated SQL query also :)
I have left minor nitpick comments.
Thanks for the review. Now I see that most of the time is template generation which is clearly less trivial. |
otherwise, we need to get the weight sum for each displayed bill. Here, we are much more scalable
And also, make it static, since it doesn't rely on instance.
af34a23
to
ba4d65d
Compare
Hi @Glandos , is there anything blocking this PR? I think it's good to go, no need to fix all performance issues (e.g. templates are another story entirely) |
For some reason Github still says that I requested some changes, but I can't find anything related to that. |
…t#949) * get weight sum along with bills to scale otherwise, we need to get the weight sum for each displayed bill. Here, we are much more scalable * add test * format * remove unused import * oops, restore pagination to 100 * add comments * format * rename method to make it clearer And also, make it static, since it doesn't rely on instance. * improve comments and naming * improve naming * missing article
Otherwise, we need to get the weight sum for each displayed bill.
Here, we are much more scalable.
With a pagination of 500, we previously had 507 queries if bill currencies were project's default, and nearly the double if not.
Now, we are down to 7.
On my Ryzen 4750G, Flask-debug toolbar profiler told me that displaying 500 out of 1000 bills drop from 2200ms to less than 1000ms.
More performance are expected in other PR.
Finally fixes #159 by continuing #161