Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112690
MIME-Version: 1.0
In-Reply-To: <CAJpLVh1G4x6+t8nT6BjvG4HBdwLwYtpz8qVrkCQ8JXEpGnm8Jw@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>
 <20df5745-f2e0-418c-94c1-46bd7712592a@www.fastmail.com> <CAJpLVh1G4x6+t8nT6BjvG4HBdwLwYtpz8qVrkCQ8JXEpGnm8Jw@mail.gmail.com>
Date: Wed, 30 Dec 2020 22:47:00 +0000
Message-ID: <CAJpLVh1Ek+CH6eC5arT2OVSTgtEWR=8tY4ZcDdts-FeOwRNWyg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Analysis of property visibility, immutability, and
 cloning proposals
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2020-12-30 21:27 GMT, Olle H=C3=A4rstedt <olleharstedt@gmail.com>:
> 2020-12-30 20:37 GMT, Larry Garfield <larry@garfieldtech.com>:
>> 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 immutability is pushed into the ecosystem
>>> > as a
>>> > silver bullet. Main reason functional languages are using it is
>>> > because
>>> > ownership is a newer concept, so it hasn't been adapted as much.
>>>
>>> Tiny benchmark here:
>>> https://gist.github.com/olleharstedt/eaaf1dd40be541f84aa0f3954a0ea54a
>>>
>>> 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
>> invocation
>> 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/Crell/848568124e25c8c83fc4da5455063bab
>>
>> Which is only ~20% slower.  And that's when dealing with very small
>> numbers,
>> so in most cases you're unlikely to notice a difference unless you reall=
y
>> are iterating over something a million times.
>>
>> I also tossed some big string properties into the class, and while the
>> total
>> time went up a bit the ratio between the two stayed about the same.
>>
>> --Larry Garfield
>
> Oh yeah. Huh. Didn't realize method calling was expensive. :) Another
> good reason to not use setters, lol. On my machine it's ~70% slower
> with "with" now (running multiple runs, using bash "time").
>
> The performance might matter when frameworks start to adapt patterns
> like this. It's already in PSR, with the HTTP message interface etc.
> Now I'm curious how OCaml and JS performs with a similar benchmark.
> Since they both have tracing GC, and PHP uses ref counting...

Benchmarks for JS and OCaml:
https://gist.github.com/olleharstedt/eaaf1dd40be541f84aa0f3954a0ea54a

In JS, it's 5x more expensive to use spread operator vs mutate the
object fields directly (or maybe node is just not optimized well on
the ARM CPU?). In OCaml, it's a ~10% difference between destructive
update (mutable fields) and cloning. No idea what to take from that.
:)