Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125078 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id A69E51A00BD for ; Tue, 20 Aug 2024 23:53:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1724198145; bh=Q2AkEQKUKRG1n6t8PjzeFvmDgn+hz6B4F24CE2RUefY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KKTbBG+0Qlk9XWKrSvItRLwWmkfIDCAMSHpLA4DzalI5YSbgS0w14KmnNgJqqqfuS DebGt4VQZKHl6T+vhLjM+yAkKLwgr0Shi1JrLeOGpOUE+xOvYC28B64JzzNynjzuPc MmvRFNJzKFVq0oxU1VnnPDtVhi1PsZ+m3hSRbTR6+OAdDrNgXCfH+ySBiM7O0uVUhO w3d15dpAE91d52KWJrZQS1pv6ORpmBDKPr+2mqyiTt6wvprDn8p9cNm+tzVCR17kk/ Ppk5ipDAN+GDZnxt6N9MunzorPIiAEWmOUvO+mzOFUnIX/obSEc4TYstLfrbKN+kNp xSpgC71jSFVhA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 199F5180055 for ; Tue, 20 Aug 2024 23:55:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 20 Aug 2024 23:55:41 +0000 (UTC) Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4fce6fd54ebso418938e0c.1 for ; Tue, 20 Aug 2024 16:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724198031; x=1724802831; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=W++BAW3k7zsT+K5PA11JZrYCL1zbJox5daPxEXRdoqM=; b=H2HmVAaT8vWz7MHqmnTaysOsXYQsnBJTe6MB59hGSb6Pt9lmSBorIztl7Pc9eSOgAa LTx+xJdrA/lwdFP3eV4VdJpGPU4T4rmYs3ESxnbTurXmNKOBqggoUuyFh61Iv/SjxjnE oSeHdcURg9eAAhZxcZES8UBGl1vlnh/TdokT6QFKOI9rPPXhjvDpGBEFjbx52kwCo/oB T/FMzl+DzFDROUkQ47HrfQ7JPuEE8R3gTX38eXIbJRp9qIRIbRbiYvnCutaJMhaTEhex kzYDGxov67lgLI7K24hMhpBiPnqeLXgyNUWTjH552+1Yhe7odv9/beIL4AlAdATzvSmN nJDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724198031; x=1724802831; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=W++BAW3k7zsT+K5PA11JZrYCL1zbJox5daPxEXRdoqM=; b=HGqaHIIwhHGll9s8veVOGr48MW7aYVlzXeBHhLNeMgH5Q2EYq1yLhFB0Ix/jyIV2Tb 5dZkU3jsTgTdjyO03W+YLJs2dslK62J2bLE7L7K5eZW8jJj9s3Tr99gKIWrZ1DT4EutP f07RI15PP2XNDB9pNTpTe3m95HxSVGbTwKuDbMYWj5zW0xfvq+HjwekWlE9FI78ukxpb y4haaKwx0Jg9+wqbTqZGGRvp4zpt15TCSmXZg2WB4nA6xnoxRkAjyoVWfhcIavY+dlRb bBbDh3uH/2Lohk60xQhJB22DP2CKnnCAg3CAKYm//0+WOJ4RzChwoIbEeIuvAxaKq/QM knJA== X-Gm-Message-State: AOJu0Yw4S5M+3mRLm78hqgzi/f8J2+LKkQvk0yt/2FhoYPM9Jun/vzLx ws8y08+egXpA9jvdH1sPRNNEqBgEWfPdwesv0TM+MpIT0oQ+YAcot8qDJlmZcB7WSw9Vqvw5p+M Q0bMucZng85acnFR+LL8PP4YUOYBfcg== X-Google-Smtp-Source: AGHT+IHYpJbwLFTUR0aVPMJw7/0lRtTddJH6kqIfrvbEV3FSMGSvtrzI4U8k7Tb+kvMKJVK4cZoEE1EByNghI+czsso= X-Received: by 2002:a05:6122:4789:b0:4f5:27ac:ce85 with SMTP id 71dfb90a1353d-4fcf19adee2mr1319211e0c.3.1724198031051; Tue, 20 Aug 2024 16:53:51 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <2716f729-4008-4f75-8412-861d8960b746@app.fastmail.com> <26338153-6d16-456a-81bf-8231bdaf1b79@app.fastmail.com> <6197f6e1-d123-41e1-87c8-887c6508bfa2@rwec.co.uk> <97d993ee-c558-43a1-a36a-8e06aa2d829a@app.fastmail.com> <1E9FCFA6-4FAD-4F47-9FC6-6AA8F2FD6BBF@rwec.co.uk> <00ee5318-329c-4a85-a2cd-1fc7050103ba@app.fastmail.com> In-Reply-To: Date: Tue, 20 Aug 2024 18:53:40 -0500 Message-ID: Subject: Re: [PHP-DEV] function autoloading v4 RFC To: Rob Landers Cc: PHP Developers Mailing List Content-Type: multipart/alternative; boundary="00000000000029d25406202623ed" From: mweierophinney@gmail.com ("Matthew Weier O'Phinney") --00000000000029d25406202623ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 20, 2024, 4:56=E2=80=AFPM Rob Landers wrote= : > > > On Tue, Aug 20, 2024, at 18:07, Rob Landers wrote: > > On Tue, Aug 20, 2024, at 08:50, Rowan Tommins [IMSoP] wrote: > > > > On 20 August 2024 00:21:22 BST, Rob Landers wrote: > > > >I assume you are worried about something like this passing test? > > > >--TEST-- > >show called only once > >--FILE-- > > > > >namespace test; > > > >spl_autoload_register(function($name) { > > echo "name=3D$name\n"; > >}, true, false, SPL_AUTOLOAD_FUNCTION); > > > >echo strlen('foo'); > >echo strlen('bar'); > >echo strlen('baz'); > >?> > >--EXPECT-- > >name=3Dtest\strlen > >333 > > > >In my RFC, I mention it is called exactly once. > > > I haven't looked at the PR, only the RFC, and I did not see this very > important detail explained anywhere. The only thing I can see is this > rather ambiguous sentence: > > > The function autoloader will not be called again. > > That could mean not called again for the current call (compared with > proposals that call it a second time with the unequalled name); it could > mean not called again for the current line of code (based on the current > caching behaviour); or never called again for that combination of namespa= ce > and name; or possibly, never called again for that combination of > namespace, name, and callback function. > > That's not a small detail of the implementation, it's a really fundamenta= l > difference from previous proposals. > > So I would like to repeat my first response to your RFC: that it should > sound more time explaining your approach to the multiple lookup problem. > > Regards, > Rowan Tommins > [IMSoP] > > > Thanks Rowan, > > That's a fair critique. > > I expect some of the wording will be more clear once I write out the > documentation -- even if it isn't used directly, I tend to write out > documentation to force myself to reconcile the code with the plan, find > logic bugs, perform larger scale tests, and create tests to verify > assertions in the documentation. From there, I'll update the plan or code > to get everything to match and spend some time on clarity. It's the harde= st > part, IMHO, as it requires diligently ensuring everything is correct. In > other words, writing the documentation makes it feel like a "real thing" > and it triggers what small amount of perfectionism I have. > > =E2=80=94 Rob > > > I have an experimental library that I use for testing these kinds of > things. There are aspects of it that I could work with to make use of > function autoloading. Thus, I did so and benchmarked the performance of > unit tests. The unit testing library makes a ton of "unqualified function > calls". > > I spent some time working on two autoloaders: > > 1. A naive autoloader: parses out the file to load, checks if it > exists, and then requires the file. > 2. An optimized autoloader: only cares about the namespace it has > registered. All others are an instant return. > > Not to sound flippant, but you do realize that composer does a lot of optimizations just like this, right? PSR-4 exists in large part due to a realization that better optimizations were possible when you mapped namespaces to source code directories. And Composer takes it a step further when you have it create an optimized loader, because then it maps classes directly to the files that provide them, preventing I/O up to the point that a require is performed. My point is that this is why folks have been suggesting that this is a solved problem. Globally qualify functions, and you get immediate performance benefits due to removal of the need to look up via the namespace first. Most CS tools will even add the imports or qualifiers for you, and you can have your IDE or editor configured to do it as well. I wouldn't spend your time on this facet. > 1. > > In the "vanilla" case, I was mostly concerned with variation. I wanted a > statistically significant result, so once I got my system into a stable > state and I was no longer seeing any variance, I started benchmarking. > > For the naive autoloader, I saw a performance degradation of about 6% and > lots of variability. This is probably due to the "file_exists" check bein= g > done every time an unqualified name was called. > > However, for the optimized autoloader, I ended up with less variability > (=F0=9F=A4=94) than the vanilla approach and absolutely no measurable per= formance > degradation. > > Now, time to try this on a larger scale... WordPress. It's pretty much th= e > only large codebase I know of that makes use of tons of functions. > > =E2=80=94 Rob > --00000000000029d25406202623ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 20, 2024, 4:56=E2=80=AFPM Rob Landers <= rob@bottled.codes> wrote:


On Tue, Aug 20, 2024, at 18:07, Ro= b Landers wrote:
On Tue, Aug 20, 2024, at 08:50, Rowan Tommins [IMSoP] wrote:

On 20 August 2024 00:21:22 BST, Rob Landers <= ;= rob@bottled.codes> wrote:
>
>I ass= ume you are worried about something like this passing test?
&= gt;
>--TEST--
>show called only once
<= /div>
>--FILE--
><?php
>
>namespace test;
>
>spl_autolo= ad_register(function($name) {
>=C2=A0=C2=A0=C2=A0 echo &qu= ot;name=3D$name\n";
>}, true, false, SPL_AUTOLOAD_FUN= CTION);
>
>echo strlen('foo');
>echo strlen('bar');
>echo strlen(&= #39;baz');
>?>
>--EXPECT--
>name=3Dtest\strlen
>333
>
<= /div>
>In my RFC, I mention it is called exactly once.


I haven't looked at the PR, only the RFC= , and I did not see this very important detail explained anywhere. The only= thing I can see is this rather ambiguous sentence:

>=C2=A0 The function autoloader will not be called again.=C2=A0

That could mean not called again for the current= call (compared with proposals that call it a second time with the unequall= ed name); it could mean not called again for the current line of code (base= d on the current caching behaviour); or never called again for that combina= tion of namespace and name; or possibly, never called again for that combin= ation of namespace, name, and callback function.

That's not a small detail of the implementation, it's a really f= undamental difference from previous proposals.=C2=A0

So I would like to repeat my first response to your RFC: that it sho= uld sound more time explaining your approach to the multiple lookup problem= .

Regards,
Rowan Tommins
[IMSoP]


Tha= nks Rowan,

That's a fair critique.

I expect some of the wording will be more clear once = I write out the documentation -- even if it isn't used directly, I tend= to write out documentation to force myself to reconcile the code with the = plan, find logic bugs, perform larger scale tests, and create tests to veri= fy assertions in the documentation. From there, I'll update the plan or= code to get everything to match and spend some time on clarity. It's t= he hardest part, IMHO, as it requires diligently ensuring everything is cor= rect. In other words, writing the documentation makes it feel like a "= real thing" and it triggers what small amount of perfectionism I have.=

= =E2=80=94 Rob

I have an experimen= tal library that I use for testing these kinds of things. There are aspects= of it that I could work with to make use of function autoloading. Thus, I = did so and benchmarked the performance of unit tests. The unit testing libr= ary makes a ton of "unqualified function calls".
I spent some time working on two autoloaders:
    A naive autoloader: parses out the file to load, checks if it exists, and= then requires the file.
  1. An optimized autoloader: only cares ab= out the namespace it has registered. All others are an instant return.
    <= /li>

Not to sound flippant, but you do realize that composer does a l= ot of optimizations just like this, right?

PSR-4 exists in large part due to a realization that bet= ter optimizations were possible when you mapped namespaces to source code d= irectories. And Composer takes it a step further when you have it create an= optimized loader, because then it maps classes directly to the files that = provide them, preventing I/O up to the point that a require is performed.= =C2=A0

My point is that = this is why folks have been suggesting that this is a solved problem. Globa= lly qualify functions, and you get immediate performance benefits due to re= moval of the need to look up via the namespace first. Most CS tools will ev= en add the imports or qualifiers for you, and you can have your IDE or edit= or configured to do it as well.=C2=A0


I wouldn't spend your time on= this facet.

In the "vanilla" case, I was mostly concerned with variation. I = wanted a statistically significant result, so once I got my system into a s= table state and I was no longer seeing any variance, I started benchmarking= .

For the naive autoloader, I saw a performan= ce degradation of about 6% and lots of variability. This is probably due to= the "file_exists" check being done every time an unqualified nam= e was called.

However, for the optimized autol= oader, I ended up with less variability (=F0=9F=A4=94) than the vanilla app= roach and absolutely no measurable performance degradation.
<= br>
Now, time to try this on a larger scale... WordPress. It'= s pretty much the only large codebase I know of that makes use of tons of f= unctions.

=E2=80=94 Rob
--00000000000029d25406202623ed--