[17.0][IMP] website_sale_stock_provisioning_date: reuse computed free quantity

[pilarvargas-tecnativa]

The combination info already contains the available quantity computed by website_sale_stock, but the provisioning date computation calculates it again.

For products with many variants displayed in a matrix, this redundant stock computation is repeated for every combination, significantly increasing the number of queries and the page loading time.

Reuse the already computed free_qty instead.

@Tecnativa TT64745

@pedrobaeza @carlos-lopez-tecnativa please review

[pedrobaeza]

Oh, check the CI (maybe a glitch?)

[pilarvargas-tecnativa]

Oh, check the CI (maybe a glitch?)

This change was proposed as part of a broader effort to optimize the overall performance of the installed website sale modules. Several modules extend the combination computation and add relatively small additional costs which, when accumulated, can have a noticeable impact on product page loading times.

However, the failing test revealed an interaction with website_sale_stock_available. That module changes the stock quantity used in the combination info, so combination_info["free_qty"] is not necessarily equivalent to the value returned by website._get_product_available_qty(product).

website_sale_stock_provisioning_date needs the latter value to determine the current stock availability before computing the next provisioning date. Therefore, reusing the value already present in combination_info, although more efficient, changes the expected behavior when both modules are installed.
It seems that the way to keep both modules compatible without introducing a glue module is to compute free_qty again here.

Unfortunately, this means keeping an additional stock computation. Individually these computations have a relatively small cost, but as more modules extend the same flow, the accumulated overhead becomes significant. With the current optimizations, a product with around 240 variants takes about 2.30 seconds on average to load.

In this particular case, however, the optimization does not seem appropriate because the duplicated computation is required to preserve the expected behavior of both modules.

[pedrobaeza]

Why don't you group all of them in the same PR in different commits?

[pilarvargas-tecnativa]

Why don't you group all of them in the same PR in different commits?

This change won't be merged, as we've found that the duplicated computation is needed for compatibility with website_sale_stock_available. The rest still needs further analysis, as there are many modules involved, and I'd prefer to analyze each case separately rather than group everything in a single PR that could end up blocked if one of the proposed optimizations doesn't fit, as happened with this one.

[pedrobaeza]

Uhm, but isn't a fact that this is calling again the method? We should optimize that and also a duplicated call.