odoo
[FW][PERF] product: speed up _create_variant_ids with lots of exclusions
When there are a relatively high number of exclusions + a lot of combinations for a given product_template, create_variant_ids can become slow. The main bottlneck is the call to _is_combination_possible_by_config. More specifically, calling attribute_lines.product_template_value_ids and
self._get_own_attribute_exclusions for each combination is pretty slow.
To speed that up, this commit introduces a new method, _filter_combinations_impossible_by_config. This method accepts a sequence of combinations and yield those that are valid w.r.t. the exclusions. Because values that only depends on self are computed once before looping through the combinations, this lead to a significant speedup. This method is a generator to avoid MemoryErrors, be able to raise a UserError after "creating" 1000 variants and be consistent with choices made in _create_variant_ids. https://github.com/odoo/odoo/blob/0042b9d3eece219d4e89fe9c6ecb9971a1f3bf12/addons/product/models/product_template.py#L710
speedup
Customer saas-16.4 database with 378 templates, 3832 products, 44 product.attributes, 186 product.attribute.values, 79 product.template.attribute.lines, 484 product.template.attribute.values, 374 product.template.attribute.exclusions. No dynamic attributes.
Timing to write on product.template, adding a new attribute value on a ProductTemplate Form increasing the number of combinations.
| Combinations | Before PR | After PR |
|---|---|---|
| 4 | 219ms | 218ms |
| 55 | 785ms | 440ms |
| 216 | 1.36s | 592ms |
| 1 944 | 28s | 809ms |
| 33 048 | 5min30s | 3.78s |
| 231 336 | +15min (timeout) | 12s |
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#164191 Forward-Port-Of: odoo/odoo#162239
This PR targets saas-17.1 and is part of the forward-port chain. Further PRs will be created up to master.
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port
@AurelienVD child PR odoo/odoo#165819 was modified / updated and has become a normal PR. This PR (and any of its parents) will need to be merged independently as approvals won't cross.
