Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113507
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Storing the lcname of symbols
Thread-Index: AQHXE3ZQtmV+o4XnfkmGnmiMAX+vqap6SZyAgAguzr4=
Date: Sat, 13 Mar 2021 21:57:55 +0000
Message-ID:
 <DM6PR07MB6618EA045D75AF84C44FE986F96E9@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <CAFMT4NonUT_NkcTcU0eMHr0Kas4Q3E6eknwRJW-Kjsof4P-T1g@mail.gmail.com>,<CAAKU0unzJAwX-hsyyu6b=FFmTLJ_b=+UH-P6VxnQARg-Eq5giw@mail.gmail.com>
In-Reply-To:
 <CAAKU0unzJAwX-hsyyu6b=FFmTLJ_b=+UH-P6VxnQARg-Eq5giw@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [UZFH+jNLQ0gO5pmUmEUlKIaPg0nrcaXTFkPrrfv2dyfh39UVSoSAlmIycmFbLYxf]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: abccb58e-25c2-46f8-9d5e-08d8e66b0ed6
x-ms-traffictypediagnostic: MW2NAM12HT204:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 lCxmFU+NRQ/84T9VfyV/t9cpfE54xHBLCRIRYxAFuybNmOC0tQYZ6xQYGefDFJCfE9FcbqeR8wPB5C0dTywCPIyERbQmtMkxFDxZdce1qiTgRO11vdU8EraExi4/j9CiM6YYPAyT4L1y4/p9aF0a8XSbB5Nx8qMjT9H0CSq5m5JnnzlIicAxuQxsQy84XBExMHa/s8cQTb0NF8jFLGkIxhdcOn24x66LcfHyg9e5Y0CR+YsXng5SMKK/J8oS0rFZbTf0gJJ8RMz1xlYZnzsTaiVGjFjU/pFhDikKT1Dy+2zepCBjm/ybTcB2IP7PDL2lUeEpnHoMaWer3YQxgEGTEXZfSzQlSIuLOJjR4Egzjo0qqsW5ELqh6278f5rQ/yKSDpN6wxHsWSMFJb4w1ZS8NgQFdq9eW8TPN0UD66vfgoIXD7qV5WdN5/zNrcHcKT9G
x-ms-exchange-antispam-messagedata:
 /ZrAuvU6yMMy8ibxvMLhaakZMhz4eRPv5mEFTQ3XzFXx2G/6YoGszndl+a9sX86+Sov6ZhdEroYB4UEZcRHV67RbPRc2fhOJ4Ip9HkMikYJQmqWy9v12XWx57dXTVL0tJL2mRHX0EhIbC3pTBBT7mdzOHtCAvanUkOrQihtmIhTaBBgpxDYRC3epGVHsawC8CXkvVktlcyFQ6tfx73kMjw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT044.eop-nam12.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: abccb58e-25c2-46f8-9d5e-08d8e66b0ed6
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2021 21:57:55.6710
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM12HT204
Subject: Re: [PHP-DEV] Storing the lcname of symbols
From: tysonandre775@hotmail.com (tyson andre)

Hi Levi Morrison,=0A=
=0A=
> > Hello!=0A=
> >=0A=
> > Most of PHP's symbols are case insensitive. This means extensions that=
=0A=
> > need to do things with function and method names end up lowercasing=0A=
> > and hashing the lowercased names, often having to do more memory=0A=
> > allocations too. Since case insensitive symbols is language dictated=0A=
> > behavior, it makes sense to expose the correctly cased symbols to=0A=
> > extensions. In PHP 8.0 (and possibly older, I did not check), the=0A=
> > engine is already interning the lowercased name of user defined=0A=
> > functions; it's just not made available to extensions.=0A=
> >=0A=
> > In my ideal world, we'd actually switch all symbols to be case=0A=
> > sensitive. However, that won't be happening for PHP 8 due to BC.=0A=
> >=0A=
> > So, instead, I propose adding an `.lcname` member (or some other name=
=0A=
> > indicating it's been normalized to the preferred PHP case) to at least=
=0A=
> > zend_op_array and zend_class_entry, but preferably for internal=0A=
> > functions too. Note that many internal functions will already be=0A=
> > lowercase, so the data can be shared.=0A=
> >=0A=
> > I could make this change in the main engine, but I strongly suspect it=
=0A=
> > will not play correctly with opcache.=0A=
> >=0A=
> > --=0A=
> > PHP Internals - PHP Runtime Development Mailing List=0A=
> > To unsubscribe, visit: https://www.php.net/unsub.php=0A=
> =0A=
> I just realized I didn't ask any specific questions. Oops:=0A=
> =0A=
> =A01. Can anyone think of issues except increased memory due to=0A=
> increasing the size of the struct? Since the strings were previously=0A=
> interned, I don't think the strings themselves will have much effect=0A=
> on memory usage (but we can measure this).=0A=
> =A02. Anyone else who thinks this would be useful?=0A=
=0A=
I don't have a personal use case for this and no common operations come to =
mind but could be persuaded.=0A=
The lack of examples or might be why there's been no response.=0A=
I assume the overhead is probably negligible for classes, and larger for fu=
nctions.=0A=
What fields of zend_op_array did you mean?=0A=
=0A=
What parts of the engine or extensions would use the lowercase string? =0A=
I see a few places it's used for compilation in php-src itself but nothing =
that seems performance critical.=0A=
=0A=
What are examples of functionality/functions of extensions that you expect =
would see a performance improvement?=0A=
Why would they need to convert the strings to lowercase rather than use the=
 casing of the declaration=0A=
(e.g. using "memcached" instead of "Memcached" in "class Memcached{...}")=
=0A=
=0A=
E.g. if something had already looked up the `zend_class_entry *ce` for a cl=
ass name, than `ce->name`=0A=
would be a string (and a unique pointer) such as "Memcached" that uniquely =
identifies that class's name=0A=
(unless the code is unexpectedly redeployed later with different casing)=0A=
=0A=
- They're still case sensitive in some ways, e.g. the composer autoloader i=
s case sensitive=0A=
- Changing case should be rare=0A=
=0A=
Regards,=0A=
Tyson=0A=