-
Notifications
You must be signed in to change notification settings - Fork 262
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
Computing the balance or statistics is slow on big projects #889
Labels
Comments
zorun
pushed a commit
to zorun/ihatemoney
that referenced
this issue
Oct 23, 2021
zorun
changed the title
Computing the balance or settling plan is slow on big projects
Computing the balance or statistics is slow on big projects
Oct 23, 2021
zorun
pushed a commit
to zorun/ihatemoney
that referenced
this issue
Oct 23, 2021
zorun
pushed a commit
to zorun/ihatemoney
that referenced
this issue
Oct 23, 2021
zorun
pushed a commit
that referenced
this issue
Oct 23, 2021
Ok, as a simpler solution, I managed to implement balance and statistics more efficiently in #890 : with 1000 bills, computing statistics goes from 7 seconds to 500 ms. pay_each is still used in one place: the list of bills. But thanks to pagination, it's not that costly. It would still be nice to improve it, but that's no longer blocking, so I'm closing this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Somebody reported that ihatemoney is now much slower than the previous version (4.1.5), and I can confirm using a big project.
I identified two slow actions:
For a project with 1000 bills, both actions create thousands of SQL queries like this:
I traced this query back to the
Bill.pay_each_default()
function, which is used to basically computebill_amount / total_owers_weight
(what is shown as "42 € each" in the list of bills). Each call to this function triggers the above SQL query.Some ideas to improve things:
Bill.total_owers_weight
so that we can cache the result of this expensive computation. We would need to make sure this field is recomputed when necessary.The text was updated successfully, but these errors were encountered: