> On 6 Apr 2021, at 05:05, Mark Randall wrote:
>
> On 15/03/2021 17:41, Mark Randall wrote:
>> I would like to propose the addition of a new mechanism of autoloading
>> classes - a classmap that will be consulted prior to checking the
>> spl_autoload_register'd callbacks.
>> https://wiki.php
Le 20/03/2021 à 02:59, Mike Schinkel a écrit :
- It could make XDEBUG debugging much less tedious by eliminating the
drill-down into the autoloader every time an unloaded class is referenced.
Yes ! I second that, it would be a huge win for a lot of overly
pessimistic developers that do xdebug
> On Mar 19, 2021, at 2:40 PM, Mark Randall wrote:
>
> On 19/03/2021 14:45, Nikita Popov wrote:
>> Could you please update the RFC with some performance numbers, including
>> the used methodology? The number of 5% has been floating around, but it's
>> not clear what it refers to. I'm primarily in
Please ignore my last message :(
Hi Internals,
I did a somewhat rough test to compare Composer's autoloader and the
function proposed in the RFC.
## TL;DR:
autoload_set_classmap over Composer with OPCache: 8.12%
autoload_set_classmap over Composer without OPCache: 7.93%
## Long version:
Using
Hi Internals,
I did a somewhat rough test to compare Composer's autoloader and the
function proposed in the RFC.
## TL;DR:
Composer autoloader + Opcache:
autoload_set_classmap + Opcache:
## Long version:
Using symfony/framework-bundle , symfony/console, and phpunit/phpunit,
in a new composer p
On 19/03/2021 14:45, Nikita Popov wrote:
Could you please update the RFC with some performance numbers, including
the used methodology? The number of 5% has been floating around, but it's
not clear what it refers to. I'm primarily interested in end-to-end effect,
e.g. on the symfony demo project.
On Mon, Mar 15, 2021 at 6:41 PM Mark Randall wrote:
> Hi Internals,
>
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
> https://wiki.php.net/rfc/autoload_classmap
Am 17.03.2021 um 02:51 schrieb Mark Randall :
> It will be left to the voters to decide if 5% of an extremely common
> operation is worth the few dozen lines of code required.
Just to avoid misunderstanding things: This is a 5% boost of just the
autoloading time, right?
What does this translate
On 17/03/2021 01:29, Mike Schinkel wrote:
Would core not be able to implement an add() more efficiently than a
get()/set()? I am especially concerned the get()/set() approach might require
allocating memory for the returned array for every get().
There is no good way to add features to mutat
> On Mar 16, 2021, at 1:46 PM, Levi Morrison via internals
> wrote:
>
> On Tue, Mar 16, 2021 at 11:06 AM Harm Smits wrote:
>>
>> Hey,
>>
>> First time ever replying so hope all went well.
>>
>> I believe the `autoload_set_classmap` function's signature should change
>> rather to something
> On 17 Mar 2021, at 03:11, Jordi Boggiano wrote:
>
>
> On 16/03/2021 15:02, Stephen Reay wrote:
>>> On 16 Mar 2021, at 20:07, Jordi Boggiano wrote:
>>>
>>>
>>> P.S: While I am here looking at spl_* docs, it seems to me like
>>> spl_autoload_call should be deprecated in favor of class_exi
On 16/03/2021 15:02, Stephen Reay wrote:
On 16 Mar 2021, at 20:07, Jordi Boggiano wrote:
P.S: While I am here looking at spl_* docs, it seems to me like
spl_autoload_call should be deprecated in favor of class_exists, and
spl_autoload_extensions + spl_autoload also probably should be depre
On Tue, Mar 16, 2021 at 11:06 AM Harm Smits wrote:
>
> Hey,
>
> First time ever replying so hope all went well.
>
> I believe the `autoload_set_classmap` function's signature should change
> rather to something like this:
>
> ```
> /**
> * Sets the internal autoloader to use the given classmap.
>
On Mon, Mar 15, 2021 at 12:41 PM Mark Randall wrote:
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
> https://wiki.php.net/rfc/autoload_classmap
>
>
My initial reac
Hey,
First time ever replying so hope all went well.
I believe the `autoload_set_classmap` function's signature should change
rather to something like this:
```
/**
* Sets the internal autoloader to use the given classmap.
*
* @param $mapping key value pair of classes;
* @param $merge A bool
On 16/03/2021 14:21, Larry Garfield wrote:
1) As the stated reason for this RFC is performance, have you any benchmarks to
show how much we'd win by using an engine-space lookup rather than user-space
lookup?
Performance benefit is unfortunately quite small, my tests suggest it is
in the reg
On Tue, Mar 16, 2021 at 8:02 AM Mark Randall wrote:
> On 15/03/2021 22:18, Levi Morrison via internals wrote:
> > Like any other case insensitive symbol PHP works with that comes from
> > userland, I would lower it in the engine's side of things. I would not
> > push the lowercase requirement on
On Mon, Mar 15, 2021, at 12:41 PM, Mark Randall wrote:
> Hi Internals,
>
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
> https://wiki.php.net/rfc/autoload_classm
> On 16 Mar 2021, at 20:07, Jordi Boggiano wrote:
>
> Hey,
>
> Here some perspective on this from the Composer side of things. To the best
> of my knowledge the Composer autoloader is the default autoloader used by
> most PHP projects at this point except for WordPress. I am sure there are a
Hey,
Here some perspective on this from the Composer side of things. To the
best of my knowledge the Composer autoloader is the default autoloader
used by most PHP projects at this point except for WordPress. I am sure
there are a few more outliers and people using custom autoloaders in
addit
On 15/03/2021 22:18, Levi Morrison via internals wrote:
Like any other case insensitive symbol PHP works with that comes from
userland, I would lower it in the engine's side of things. I would not
push the lowercase requirement on the API.
That was the first design, however it required re-creat
> On Mar 15, 2021, at 1:41 PM, Mark Randall wrote:
>
> Hi Internals,
>
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
> https://wiki.php.net/rfc/autoload_classm
On Tue, Mar 16, 2021 at 2:01 AM Christian Schneider
wrote:
> If the number of classes to load is indeed that big that the function call
> overhead is significant enough (I agree with Levi that some numbers
> illustrating what we're talking about would be nice), wouldn't that be a
> case for class
Am 15.03.2021 um 18:41 schrieb Mark Randall :
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
> https://wiki.php.net/rfc/autoload_classmap
Just so I understand co
On Mon, Mar 15, 2021 at 12:32 PM Mark Randall wrote:
>
> On 15/03/2021 17:59, Levi Morrison via internals wrote:
> > IMO, these should be the defined case of the class, or we should be
> > insensitive about it. It's one thing that our symbols are case
> > insensitive; it is wholly another to _requ
On 15/03/2021 17:59, Levi Morrison via internals wrote:
IMO, these should be the defined case of the class, or we should be
insensitive about it. It's one thing that our symbols are case
insensitive; it is wholly another to _require_ it for this feature by
requiring lowercase names. I assume ther
On Mon, Mar 15, 2021 at 11:41 AM Mark Randall wrote:
>
> Hi Internals,
>
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
> https://wiki.php.net/rfc/autoload_classmap
27 matches
Mail list logo
