Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125176
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 24 Aug 2024 11:00:13 +0200
To: internals@lists.php.net
Message-ID: <b213a6fb-5d0c-42a6-a3b0-ec4a50590baa@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LDra0K+hi+80swpWJJp4-t7NT3s9ufC1jfH2x5O7-P0dw@mail.gmail.com>
References: <21D6F160-5EAE-44FA-907B-E1DAAC1B8D75@rwec.co.uk>
 <53BD062A-4D7F-4E5D-852E-6D27641213A8@koalephant.com>
 <f32382b4-3bee-47ab-88ed-ad2ab154c319@app.fastmail.com>
 <7607FD64-5572-466E-9866-63C2536B2A09@koalephant.com>
 <0d269a38-28fe-494c-a903-50022e09f27b@app.fastmail.com>
 <E848530A-038F-40E0-A87D-D0C823C5E967@koalephant.com>
 <63DAE337-B117-4380-8735-186DC30FE0B7@rwec.co.uk>
 <CAPyj-LDCdo+UE0W1q6LOAVHrt6mVmGft9K4mBDvjkBWR3TT4kA@mail.gmail.com>
 <977227E3-8793-4FB1-B572-B75D27C06ED5@rwec.co.uk>
 <CAPyj-LDra0K+hi+80swpWJJp4-t7NT3s9ufC1jfH2x5O7-P0dw@mail.gmail.com>
Subject: Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then
 local)
Content-Type: multipart/alternative;
 boundary=83c2b1acac8c4e35a07d9f88002b88bd
From: rob@bottled.codes ("Rob Landers")

--83c2b1acac8c4e35a07d9f88002b88bd
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 23, 2024, at 23:57, Ilija Tovilo wrote:
> On Fri, Aug 23, 2024 at 9:41=E2=80=AFPM Rowan Tommins [IMSoP]
> <imsop.php@rwec.co.uk> wrote:
> >
> > On 23 August 2024 18:32:41 BST, Ilija Tovilo <tovilo.ilija@gmail.com=
> wrote:
> > >IMO, 1. is too drastic. As people have mentioned, there are tools to
> > >automate disambiguation. But unless we gain some other benefit from
> > >dropping the lookup entirely, why do it?
> >
> > I can think of a few disadvantages of "global first":
> >
> > - Fewer code bases will be affected, but working out which ones is h=
arder. The easiest migration will probably be to make sure all calls to =
namespaced functions are fully qualified, as though it was "global only".
>=20
> To talk about more concrete numbers, I now also analyzed how many
> relative calls to local functions there are in the top 1000 composer
> packages.
>=20
> https://gist.github.com/iluuu1994/9d4bbbcd5f378d221851efa4e82b1f63
>=20
> There were 4229 calls to local functions that were statically visible.
> Of those, 1534 came from thecodingmachine/safe, which I'm excluding
> again for a fair comparison. The remaining 2695 calls were split
> across 210 files and 27 repositories, which is less than I expected.
>=20
> The calls that need to be fixed by swapping the lookup order are a
> subset of these calls, namely only the ones also clashing with some
> global function. Hence, the process of identifying them doesn't seem
> fundamentally different. Whether the above are "few enough" to justify
> the BC break, I don't know.
>=20
> > - The engine won't be able to optimise calls where the name exists l=
ocally but not globally, because a userland global function could be def=
ined at any time.
>=20
> When relying on the lookup, the lookup will be slower. But if the
> hypothesis is that there are few people relying on this in the first
> place, it shouldn't be an issue. It's also worth noting that many of
> the optimizations don't apply anyway, because the global function is
> also unknown and hence a user function, with an unknown signature.
>=20
> > - Unlike with the current way around, there's unlikely to be a use c=
ase for shadowing a namespaced name with a global one; it will just be a=
 gotcha that trips people up occasionally.
>=20
> Indeed. But this is a downside of both these approaches.
>=20
> > None of these seem like showstoppers to me, but since we can so easi=
ly go one step further to "global only", and avoid them, why wouldn't we?
> >
> > Your answer to that seems to be that you think "global only" is a bi=
gger BC break, but I wonder how much difference it really makes. As in, =
how many codebases are using unqualified calls to reference a namespaced=
 function, but *not* shadowing a global name?
>=20
> I hope this provides some additional insight. Looking at the analysis,
> I'm not completely opposed to your approach. There are some open
> questions. For example, how do we handle functions declared and called
> in the same file?
>=20
> namespace Foo;
> function bar() {}
> bar();
>=20
> Without a local fallback, it seems odd for this call to fail. An
> option might be to auto-use Foo\bar when it is declared, although that
> will require a separate pass over the top functions so that functions
> don't become order-dependent.
>=20
> Ilija
>=20

Hey Ilija,

I'm actually coming around to global first, then local second. I haven't=
 gotten statistically significant results yet though, but preliminary re=
sults show that global first gives symfony/laravel their speed boost and=
 function autoloading gives things like wordpress their speed boost. Eve=
ryone wins.

For function autoloading, it is only called on the local check. So, it l=
ooks kinda like this:

 1. does it exist in global namespace?
   1. yes: load the function; done.
   2. no: continue
 2. does it exist in local namespace?
   1. yes: load the function; done.
   2. no: continue
 3. call the autoloader for local namespace.
 4. does it exist in local namespace?
   1. yes: load the function; done.
   2. no: continue
 5. does it exist in the global namespace?
   1. yes: load the function; done.
   2. no: continue

It checks the scopes in reverse order after autoloading because it is mo=
re likely that the autoloader loaded a local scope function than a globa=
l one. This adds a small inconsistency (if the autoloader were to load b=
oth a global and non-global function of the same name), but keeps autolo=
ading fast for unqualified function calls. By checking global first, for=
 OOP-centric codebases like Symfony and Laravel that call unqualified gl=
obal functions, they never hit the autoloader. For things that do call q=
ualified local-namespace functions, they hit the autoloader and immediat=
ely start loading them. The worst performance then becomes autoloading g=
lobal functions that are called unqualified. Not only do you have to str=
ip out the current namespace in the autoloader, but you have to deal wit=
h being the absolute last check in the function table. However, (and I'm=
 still trying to figure out how to quantify this), I'm reasonably certai=
n projects do not use global functions that often.

=E2=80=94 Rob
--83c2b1acac8c4e35a07d9f88002b88bd
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Fri, Aug 23,=
 2024, at 23:57, Ilija Tovilo wrote:<br></div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>On Fri, Aug 23, 2024 at 9:41=E2=80=AFPM Rowan =
Tommins [IMSoP]<br></div><div>&lt;<a href=3D"mailto:imsop.php@rwec.co.uk=
">imsop.php@rwec.co.uk</a>&gt; wrote:<br></div><div>&gt;<br></div><div>&=
gt; On 23 August 2024 18:32:41 BST, Ilija Tovilo &lt;<a href=3D"mailto:t=
ovilo.ilija@gmail.com">tovilo.ilija@gmail.com</a>&gt; wrote:<br></div><d=
iv>&gt; &gt;IMO, 1. is too drastic. As people have mentioned, there are =
tools to<br></div><div>&gt; &gt;automate disambiguation. But unless we g=
ain some other benefit from<br></div><div>&gt; &gt;dropping the lookup e=
ntirely, why do it?<br></div><div>&gt;<br></div><div>&gt; I can think of=
 a few disadvantages of "global first":<br></div><div>&gt;<br></div><div=
>&gt; - Fewer code bases will be affected, but working out which ones is=
 harder. The easiest migration will probably be to make sure all calls t=
o namespaced functions are fully qualified, as though it was "global onl=
y".<br></div><div><br></div><div>To talk about more concrete numbers, I =
now also analyzed how many<br></div><div>relative calls to local functio=
ns there are in the top 1000 composer<br></div><div>packages.<br></div><=
div><br></div><div><a href=3D"https://gist.github.com/iluuu1994/9d4bbbcd=
5f378d221851efa4e82b1f63">https://gist.github.com/iluuu1994/9d4bbbcd5f37=
8d221851efa4e82b1f63</a><br></div><div><br></div><div>There were 4229 ca=
lls to local functions that were statically visible.<br></div><div>Of th=
ose, 1534 came from thecodingmachine/safe, which I'm excluding<br></div>=
<div>again for a fair comparison. The remaining 2695 calls were split<br=
></div><div>across 210 files and 27 repositories, which is less than I e=
xpected.<br></div><div><br></div><div>The calls that need to be fixed by=
 swapping the lookup order are a<br></div><div>subset of these calls, na=
mely only the ones also clashing with some<br></div><div>global function=
. Hence, the process of identifying them doesn't seem<br></div><div>fund=
amentally different. Whether the above are "few enough" to justify<br></=
div><div>the BC break, I don't know.<br></div><div><br></div><div>&gt; -=
 The engine won't be able to optimise calls where the name exists locall=
y but not globally, because a userland global function could be defined =
at any time.<br></div><div><br></div><div>When relying on the lookup, th=
e lookup will be slower. But if the<br></div><div>hypothesis is that the=
re are few people relying on this in the first<br></div><div>place, it s=
houldn't be an issue. It's also worth noting that many of<br></div><div>=
the optimizations don't apply anyway, because the global function is<br>=
</div><div>also unknown and hence a user function, with an unknown signa=
ture.<br></div><div><br></div><div>&gt; - Unlike with the current way ar=
ound, there's unlikely to be a use case for shadowing a namespaced name =
with a global one; it will just be a gotcha that trips people up occasio=
nally.<br></div><div><br></div><div>Indeed. But this is a downside of bo=
th these approaches.<br></div><div><br></div><div>&gt; None of these see=
m like showstoppers to me, but since we can so easily go one step furthe=
r to "global only", and avoid them, why wouldn't we?<br></div><div>&gt;<=
br></div><div>&gt; Your answer to that seems to be that you think "globa=
l only" is a bigger BC break, but I wonder how much difference it really=
 makes. As in, how many codebases are using unqualified calls to referen=
ce a namespaced function, but *not* shadowing a global name?<br></div><d=
iv><br></div><div>I hope this provides some additional insight. Looking =
at the analysis,<br></div><div>I'm not completely opposed to your approa=
ch. There are some open<br></div><div>questions. For example, how do we =
handle functions declared and called<br></div><div>in the same file?<br>=
</div><div><br></div><div>namespace Foo;<br></div><div>function bar() {}=
<br></div><div>bar();<br></div><div><br></div><div>Without a local fallb=
ack, it seems odd for this call to fail. An<br></div><div>option might b=
e to auto-use Foo\bar when it is declared, although that<br></div><div>w=
ill require a separate pass over the top functions so that functions<br>=
</div><div>don't become order-dependent.<br></div><div><br></div><div>Il=
ija<br></div><div><br></div></blockquote><div><br></div><div>Hey&nbsp;Il=
ija,<br></div><div><br></div><div>I'm actually coming around to global f=
irst, then local second. I haven't gotten statistically significant resu=
lts yet though, but preliminary results show that global first gives sym=
fony/laravel their speed boost and function autoloading gives things lik=
e wordpress their speed boost. Everyone wins.<br></div><div><br></div><d=
iv>For function autoloading, it is only called on the local check. So, i=
t looks kinda like this:<br></div><div><br></div><ol><li>does it exist i=
n global namespace?<br></li><ol><li>yes: load the function; done.<br></l=
i><li>no: continue<br></li></ol><li>does it exist in local namespace?<br=
></li><ol><li>yes: load the function; done.<br></li><li>no: continue<br>=
</li></ol><li>call the autoloader for local namespace.<br></li><li>does =
it exist in local namespace?<br></li><ol><li>yes: load the function; don=
e.<br></li><li>no: continue<br></li></ol><li>does it exist in the global=
 namespace?<br></li><ol><li>yes: load the function; done.<br></li><li>no=
: continue<br></li></ol></ol><div><br></div><div>It checks the scopes in=
 reverse order after autoloading because it is more likely that the auto=
loader loaded a local scope function than a global one. This adds a smal=
l inconsistency (if the autoloader were to load both a global and non-gl=
obal function of the same name), but keeps autoloading fast for unqualif=
ied function calls. By checking global first, for OOP-centric codebases =
like Symfony and Laravel that call unqualified global functions, they ne=
ver hit the autoloader. For things that do call qualified local-namespac=
e functions, they hit the autoloader and immediately start loading them.=
 The worst performance then becomes autoloading global functions that ar=
e called unqualified. Not only do you have to strip out the current name=
space in the autoloader, but you have to deal with being the absolute la=
st check in the function table. However, (and I'm still trying to figure=
 out how to quantify this), I'm reasonably certain projects do not use g=
lobal functions that often.<br></div><div><br></div><div id=3D"sig121229=
152">=E2=80=94 Rob<br></div></body></html>
--83c2b1acac8c4e35a07d9f88002b88bd--