Problem: Sales document is running very slow when it has many items, crashing screen when adding an item or editing quantity/value, freezing time may vary from user hardware.
I have a bad performance runing javascripts, when i do a sales order or sales invoice with many itens.
i have identify a method who make this problem, taxes_and_totals.js, method calculate_item_values.
This method is called 4 times when i insert a item on sales invoice.
But the real problem is the method “precision”, this called alot of time, i know precision must be setted…
but if I don’t call and manually set the decimal precision, the runtime goes from 4 seconds to 60 ms
The problem is: precision(field, item)
Anyone has this problem too? my version is v13.13.0
First I was commenting code, until I found what was causing the slowness, I found _calculate_rates_and_totals, then I put a runtime calculation.
After that I went back to find out which of the methods that were running in that scope of code that was generating the slowness, I found the function “calculate_item_values”.
So I started trying it out, until I found that overrunning precision(fieldname, doc) is causing this slowness.
Very nice analysis. For me the issues are never reproducible enough to go into that direction.
But with your results it motivates me to investigate again.
I believe that the method “frappe.model.round_floats_in” should receive the fields that must be updated, but it is a little complex to know what will impact passing the specific fields.
with the original code, in a situation with 49 items, adding the 50 item, it takes 5.2 seconds to add the new item.
Passing the specific fields takes 2.3 seconds.
However, this is still not a good result, considering that my computer is very good, as javascript runs on the client, if his computer is bad, it will be slower…
I don’t think so, because it’s not running in a loop.
The problem with round_floats_in is that it executes all quantity and money fields item by item. besides calling the calculate_item_values method 4 times. which makes the whole process even slower.
2 - on price_list_rate function, dont make sense price_list_rate call “calculate_taxes_and_totals”, because on rate change value “calculate_taxes_and_totals” will be called…
I optimized the execution time of the method “calculate_item_values”, in my situation it went from 1300ms to 320ms.
1 - I created a new method “round_floats_childs_in”, it has the same purpose as “round_floats_in”, but it aims to get precision() only once for each field in the first position of the loop, then for the other positions of the for use this value of the local variable.
that sounds really nice and impressive! i will try to recreate your improvements in my environment in the next few days.
do you have the code already checked in somewhere?