Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123759
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------D9WAVzhUJ3Ekpb0TIDSxJPvg"
Message-ID: <2d796f4f-d6c2-4ae6-aa2b-a281a0768e99@rwec.co.uk>
Date: Sat, 22 Jun 2024 21:48:23 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
To: internals@lists.php.net
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <02ee8831-43a0-4857-886e-7f54fb42a99d@varteg.nz>
 <CAB-Buja2B0_idnmjZFDNiQrGSRck-z-G7M1v8dNQ6ZyCf482OQ@mail.gmail.com>
 <CAPzBOBNLFmGESU-OEfp+ZVXdzKQ_H+yBT2Ak-hcrm1ZK25kUQA@mail.gmail.com>
 <7d825b1d-e584-4916-9435-3561b9c54c26@gmail.com>
 <CAPzBOBNLfccuXNzcsgf-2-JpJeGNXu2jVGsA-+Fkhbu0+sGBdA@mail.gmail.com>
 <CAP1Jc10RBiSY_bosS90LBxBjccj6_rNsr_f68yo8Rhos=axQJg@mail.gmail.com>
 <CAPzBOBM1ox1Bk0V37tin76Ofn_cDn5EHXgUga1Pss0LK7JGncA@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAPzBOBM1ox1Bk0V37tin76Ofn_cDn5EHXgUga1Pss0LK7JGncA@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------D9WAVzhUJ3Ekpb0TIDSxJPvg
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 22/06/2024 21:15, Robert Landers wrote:
> To me, that sounds kinda silly. PHP does reference counting and while
> there is an overhead, it doesn't prevent us from using it...


The reference count is a single pre-allocated integer on the C struct 
holding the value; and even then, a lot of effort was put in during the 
"PHP-NG" project (which landed in PHP 7.0) to avoid reference counting 
values that didn't need it. (Nikita wrote a great post explaining the 
changes here: 
https://www.npopov.com/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html)

The problem with type counters is not just that there's more than one 
per array, it's that there's a *variable* number, so you can't 
preallocate memory for them, they need to reference some extra resizable 
hash-table. That's the "indirection" that Arnaud is talking about.

I've thought in the past about caching type checks that had passed, so 
that a series of array<int> checks could be made "for the price of one" 
if the array didn't change between. That might at least mean the 
additional table of types would only need accessing on type checks, not 
every write, but a lot of checks would still need to iterate the whole 
array.

Having a structure that only allows one type could potentially be much 
more efficient, because you only need to allocate space for the type 
identifier, and check against it on write.


-- 
Rowan Tommins
[IMSoP]

--------------D9WAVzhUJ3Ekpb0TIDSxJPvg
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 22/06/2024 21:15, Robert Landers
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPzBOBM1ox1Bk0V37tin76Ofn_cDn5EHXgUga1Pss0LK7JGncA@mail.gmail.com">
      <pre>To me, that sounds kinda silly. PHP does reference counting and while
there is an overhead, it doesn't prevent us from using it...</pre>
    </blockquote>
    <p><br>
    </p>
    <p>The reference count is a single pre-allocated integer on the C
      struct holding the value; and even then, a lot of effort was put
      in during the "PHP-NG" project (which landed in PHP 7.0) to avoid
      reference counting values that didn't need it. (Nikita wrote a
      great post explaining the changes here:
<a class="moz-txt-link-freetext" href="https://www.npopov.com/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html">https://www.npopov.com/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html</a>)<br>
    </p>
    <p>The problem with type counters is not just that there's more than
      one per array, it's that there's a *variable* number, so you can't
      preallocate memory for them, they need to reference some extra
      resizable hash-table. That's the "indirection" that Arnaud is
      talking about.</p>
    <p>I've thought in the past about caching type checks that had
      passed, so that a series of array&lt;int&gt; checks could be made
      "for the price of one" if the array didn't change between. That
      might at least mean the additional table of types would only need
      accessing on type checks, not every write, but a lot of checks
      would still need to iterate the whole array.<br>
    </p>
    <p>Having a structure that only allows one type could potentially be
      much more efficient, because you only need to allocate space for
      the type identifier, and check against it on write.<br>
    </p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------D9WAVzhUJ3Ekpb0TIDSxJPvg--