Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113418
MIME-Version: 1.0
References: <CAFMT4NonUT_NkcTcU0eMHr0Kas4Q3E6eknwRJW-Kjsof4P-T1g@mail.gmail.com>
In-Reply-To: <CAFMT4NonUT_NkcTcU0eMHr0Kas4Q3E6eknwRJW-Kjsof4P-T1g@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Mon, 8 Mar 2021 09:29:53 -0700
Message-ID: <CAAKU0unzJAwX-hsyyu6b=FFmTLJ_b=+UH-P6VxnQARg-Eq5giw@mail.gmail.com>
To: Levi Morrison <morrison.levi@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Storing the lcname of symbols
From: internals@lists.php.net ("Levi Morrison via internals")

On Sun, Mar 7, 2021 at 10:21 AM Levi Morrison <morrison.levi@gmail.com> wrote:
>
> Hello!
>
> Most of PHP's symbols are case insensitive. This means extensions that
> need to do things with function and method names end up lowercasing
> and hashing the lowercased names, often having to do more memory
> allocations too. Since case insensitive symbols is language dictated
> behavior, it makes sense to expose the correctly cased symbols to
> extensions. In PHP 8.0 (and possibly older, I did not check), the
> engine is already interning the lowercased name of user defined
> functions; it's just not made available to extensions.
>
> In my ideal world, we'd actually switch all symbols to be case
> sensitive. However, that won't be happening for PHP 8 due to BC.
>
> So, instead, I propose adding an `.lcname` member (or some other name
> indicating it's been normalized to the preferred PHP case) to at least
> zend_op_array and zend_class_entry, but preferably for internal
> functions too. Note that many internal functions will already be
> lowercase, so the data can be shared.
>
> I could make this change in the main engine, but I strongly suspect it
> will not play correctly with opcache.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

I just realized I didn't ask any specific questions. Oops:

 1. Can anyone think of issues except increased memory due to
increasing the size of the struct? Since the strings were previously
interned, I don't think the strings themselves will have much effect
on memory usage (but we can measure this).
 2. Anyone else who thinks this would be useful?