On Sun, Mar 17, 2024 at 5:05 PM Saki Takamachi <s...@sakiot.com> wrote:
> Hi Jordan, > > > Using a BCNum inside a loop is the use case, where every loop would > result in memory allocation for a new object, as well as the overhead of > the constructor, etc. > > > > Granted, only people who REALLY know what they are doing should be doing > this. Though my library which essentially IS a wrapped for BCMath that is > upgradeable if you install other extensions (like ext-decimal) does support > both, I suggest using primarily immutables in my docs. > > > > That said, the C library itself for BCMath is insanely inefficient as > far as arbitrary precision math goes, so I would suggest that people don't > get their hopes up too much on the performance front. > > I just sent an email, and you're right about performance. Therefore, the > point of this proposal seems to be simply to improve convenience. > > Regards. > > Saki I've done a lot of performance tuning on my arbitrary precision library, and will simply state for everyone here that I think the amount of development effort involved in improving performance of the BCMath library is almost certainly going to see a return on your effort that is not worth it. There have been discussions over the last year on possibly working on bundling a new arbitrary precision C library and providing something that is performant enough to be generally useful in core, but that's not even at the RFC stage, just investigations. I wouldn't say that improving BCMath is a waste of time, but there is also probably lower hanging fruit once you get past things like Saki has here. DevEx improvements. Jordan
