Tryton GTK client is slow on overly complicated view
I am confronted to a quite complicated view (with a lot of one2many containing themselves one2many and so one sometimes 2 or 3 levels deep).
In this setup the GTk client is slow even when all the data is present in the cache. After some digging, one of the culprits is the usage of deepcopy
in the cache mechanism (and also in the domain parser but mainly in the cache). This usage amounts to 25% of the CPU Time spent to render the form.
I have identified 3 ways of reducing the time spent while copying the data:
- Given that deepcopy tries hard to make sure that it's not confronted to a recursive structure, and that we already know that it's not a recursive structure (because it's JSON-able) we could use our own version of deepcopy (I made a quite naïve implementation that was better than the more clever one I did afterwards). This solution provides a ±20% speed up
- Instead of caching the python dictionary we should cache the raw data, deserializing the data on each hit on the cache. Quite surprisingly this solution also provides a ±20% speed up.
- We use deepcopy because we modify the fields definition (mainly to add
loading
information). If we can prevent those modifications there is no need to copy the data at all. I thus made a patch that reuse theImmutableDict
we have intrytond
and fix issues that appears. This is the best solution as it provides an almost perfect speed up of 25%.
What's your opinion about this?