Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112685
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <20df5745-f2e0-418c-94c1-46bd7712592a@www.fastmail.com>
In-Reply-To: 
 <CAJpLVh36=cXxn7-=7Gv5PoPf2aL+HUsALm3yafAEc_oaDN2fYw@mail.gmail.com>
References: <1d0abb04-4987-43a9-85bc-bccc3bd6be9a@www.fastmail.com>
 <03108284-740a-4a5d-130f-15b2e67e9df9@mabe.berlin>
 <CAJpLVh2M3iKhG8b2qZydf_70K4NYdZ5fpSEsRNK7uLeESUPHKg@mail.gmail.com>
 <459d7ff7-e553-dce9-7d43-c3b1e772e572@gmail.com>
 <CAJpLVh31UzSJvKdypQ=Mh+6CLvfUCrF==z6HBDD1_nuYqFzG5A@mail.gmail.com>
 <7f4fe9ca-1c20-6f69-cef0-a9718af742a3@gmail.com>
 <3e683903-66cb-4a1a-9ff8-22887dbb8dce@www.fastmail.com>
 <CAJpLVh1o+BmqzEN_ewQVxEoNoe1caUYHJ7QB8LTBAeu2f889fA@mail.gmail.com>
 <b3fba6e2-8547-4de6-a09f-bd980b24a97a@www.fastmail.com>
 <CAJpLVh1FhjEKgfw9v-7CMU74h4b_XKRU5t58Jd3vrLQPuVLTfw@mail.gmail.com>
 <CAJpLVh36=cXxn7-=7Gv5PoPf2aL+HUsALm3yafAEc_oaDN2fYw@mail.gmail.com>
Date: Wed, 30 Dec 2020 14:37:58 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Analysis_of_property_visibility,_immutability,_a?=
 =?UTF-8?Q?nd_cloning_proposals?=
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Dec 30, 2020, at 2:16 PM, Olle H=C3=A4rstedt wrote:

> > Ok. You have a benchmark for this? I can make one otherwise, for the=
 query
> > example.
> >
> > It worries me a little that immutablility is pushed into the ecosyst=
em as a
> > silver bullet. Main reason functional languages are using it is beca=
use
> > ownership is a newer concept, so it hasn't been adapted as much.
>=20
> Tiny benchmark here:
> https://gist.github.com/olleharstedt/eaaf1dd40be541f84aa0f3954a0ea54a
>=20
> Running this on my ARM machine with PHP 7.2 gives ~1.2s for the
> immutable loop, ~0.35s for the mutable one, meaning immutability is
> ~3x as expensive performance wise. And this is for a SMALL object - I
> suspect the performance hit will grow the bigger the class gets (more
> properties to clone). Correct me if I'm wrong. :/


That's not a valid benchmark; it's comparing cloning and method invocati=
on against just property sets.  The method calls are chewing up most of =
the time there.

Here's a more fair comparison on my laptop: https://gist.github.com/Crel=
l/848568124e25c8c83fc4da5455063bab

Which is only ~20% slower.  And that's when dealing with very small numb=
ers, so in most cases you're unlikely to notice a difference unless you =
really are iterating over something a million times.

I also tossed some big string properties into the class, and while the t=
otal time went up a bit the ratio between the two stayed about the same.=


--Larry Garfield