Implement BCMath LRU cache

[nielsdos]

This is a prototype for an LRU cache for operands used in BCMath.

We notice in profiles that parsing operands takes a long time (like over 30% for the benchmark in #14076).
This PR implements a cache for the 16 most recently used operands, such that parsing can be avoided. The underlying idea is that in a particular time window the same operands are likely to be used again (*).

This implementation could probably be improved too performance-wise.
Important: One notable thing missing is that results are not stored in the LRU cache yet.

(*) The question is whether this is true in real-world use-cases. If this is not true most of the time, then a patch like this will cause a performance degradation because maintaining the LRU also has some overhead.

[nielsdos]

cc @Girgias @SakiTakamachi Let me know if you're aware of real-world test cases we could try this on and what your opinion on something like this is.

[SakiTakamachi]

A typical use case for BCMath is money calculations.

That is, if BCMath needs to convert the same string multiple times, it could be a value such as an interest rate percentage, a discount percentage, a tax rate, or a fixed discount amount.

Those values ​​should be relatively short, so the benefit may not be much.

(These are the only answers I can think of right now, there may be other use cases.)

[nielsdos]

Right, would still be nice to have specific numbers.
One thing that might help in the case of money calculations is caching the result too. When a result is then used in a subsequent calculation we can avoid parsing it.
I think that would be quite common because people often use results from one calculation in a further calculation.
What do you think?

[SakiTakamachi]

One thing that might help in the case of money calculations is caching the result too. When a result is then used in a subsequent calculation we can avoid parsing it.
I think that would be quite common because people often use results from one calculation in a further calculation.

Yes, that use case definitely exists.

Note however that if BCMath were to support object types, it would keep bc_num inside the object, so this cache may be dedicated to existing functions only.

[frederikbosch]

You might want to use the BcMathCalculatorBench included in MoneyPHP.

[nielsdos]

You might want to use the BcMathCalculatorBench included in MoneyPHP.

Thanks for the pointer, this will be useful for our testing!
I'll test that with this PR sometime later.

[Girgias]

Code looks logical, will wait for benchmark results

[nielsdos]

Running the moneyphp benchmark showed that this has no benefit, at least for that testcase: I see some small gains and some larger losses.
The problem is that in that benchmark only very small numbers are tested, so the overhead of caching then outweighs the gains we would get. If the benchmark were to use larger numbers then we would see different results. So I'll hold off on this.

[nielsdos]

Closing this as this will not move forward in its current state.