Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112688
MIME-Version: 1.0
In-Reply-To: <20df5745-f2e0-418c-94c1-46bd7712592a@www.fastmail.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>
Date: Wed, 30 Dec 2020 21:27:31 +0000
Message-ID: <CAJpLVh1G4x6+t8nT6BjvG4HBdwLwYtpz8qVrkCQ8JXEpGnm8Jw@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 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 becaus=
e
>> > 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 invocatio=
n
> 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 numbe=
rs,
> 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 to=
tal
> 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...