Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122675
Precedence: bulk
MIME-Version: 1.0
References: <a1f10f65-2d44-45bf-8692-51398c168bbe@redmagic.org.uk>
 <09F87F91-6538-48D2-9E34-0296E02CCC1A@sakiot.com> <CAMrTa2E=-QWHrJG2biPYmDtSJBvx5Er0r44AaOHqk2FRRkzs_g@mail.gmail.com>
 <7FC4C53E-BDA1-40DA-BFE3-EE068C63444F@sakiot.com>
In-Reply-To: <7FC4C53E-BDA1-40DA-BFE3-EE068C63444F@sakiot.com>
Date: Sun, 17 Mar 2024 17:54:26 -0700
Message-ID: <CAMrTa2EEy6dsgUW=EbtuA1V+H4D4vcHmVLdnBcQHcY--ta+TdA@mail.gmail.com>
Subject: Re: [PHP-DEV] Supporting object types in BCMath
To: Saki Takamachi <saki@sakiot.com>
Cc: Barney Laurance <barney@redmagic.org.uk>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c581950613e4cd52"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000c581950613e4cd52
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 17, 2024 at 5:05=E2=80=AFPM Saki Takamachi <saki@sakiot.com> wr=
ote:

> 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 doin=
g
> this. Though my library which essentially IS a wrapped for BCMath that is
> upgradeable if you install other extensions (like ext-decimal) does suppo=
rt
> 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

--000000000000c581950613e4cd52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 17, 2024 at 5:05=E2=80=AF=
PM Saki Takamachi &lt;<a href=3D"mailto:saki@sakiot.com">saki@sakiot.com</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi =
Jordan,<br>
<br>
&gt; Using a BCNum inside a loop is the use case, where every loop would re=
sult in memory allocation for a new object, as well as the overhead of the =
constructor, etc.<br>
&gt; <br>
&gt; Granted, only people who REALLY know what they are doing should be doi=
ng this. Though my library which essentially IS a wrapped for BCMath that i=
s upgradeable if you install other extensions (like ext-decimal) does suppo=
rt both, I suggest using primarily immutables in my docs.<br>
&gt; <br>
&gt; 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=
9;t get their hopes up too much on the performance front.<br>
<br>
I just sent an email, and you&#39;re right about performance. Therefore, th=
e point of this proposal seems to be simply to improve convenience.<br>
<br>
Regards.<br>
<br>
Saki</blockquote><div><br></div><div>I&#39;ve done a lot of performance tun=
ing on my arbitrary precision library, and will simply state for everyone h=
ere that I think the amount of development effort involved in improving per=
formance 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 las=
t 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&#39;s not even at the RFC stage, just investigations.</div>=
<div><br></div><div>I wouldn&#39;t say that improving BCMath is a waste of =
time, but there is also probably lower hanging fruit once you get past thin=
gs like Saki has here. DevEx improvements.</div><div><br></div><div>Jordan<=
br></div></div></div>

--000000000000c581950613e4cd52--