Skip to content
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

Closed
zorun opened this issue Oct 23, 2021 · 1 comment
Closed

Computing the balance or statistics is slow on big projects #889

zorun opened this issue Oct 23, 2021 · 1 comment

Comments

@zorun
Copy link
Collaborator

zorun commented Oct 23, 2021

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:

  • computing the balance (as shown in the list of bills or in the "settle bills" page)
  • computing statistics

For a project with 1000 bills, both actions create thousands of SQL queries like this:

SELECT sum(person.weight) AS sum_1 
FROM person JOIN billowers ON person.id = billowers.person_id JOIN bill ON bill.id = billowers.bill_id 
WHERE bill.id = ?

I traced this query back to the Bill.pay_each_default() function, which is used to basically compute bill_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:

  • add a new field 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.
  • rethink the data model, so that simple things don't need complicated JOIN operations.
zorun pushed a commit to zorun/ihatemoney that referenced this issue Oct 23, 2021
@zorun 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
Copy link
Collaborator Author

zorun commented 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
Projects
None yet
Development

No branches or pull requests

1 participant