Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119554
Message-ID: <7e86a2d2-b971-592c-64e3-e86c13b5be80@cubiclesoft.com>
Date: Tue, 14 Feb 2023 19:35:42 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
Content-Language: en-US
To: Rowan Tommins <rowan.collins@gmail.com>, internals@lists.php.net
References: <e352423f-b740-07c9-2c4a-996112e17bbe@cubiclesoft.com>
 <92c4514f-70e3-75c9-7084-9e29641e25e7@gmail.com>
In-Reply-To: <92c4514f-70e3-75c9-7084-9e29641e25e7@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Working With Substrings
From: thruska@cubiclesoft.com (Thomas Hruska)

On 2/14/2023 2:02 PM, Rowan Tommins wrote:
> On 14/02/2023 15:32, Thomas Hruska wrote:
>> Hello Internals,
>>
>> I would like to start the discussion on adding several functions and 
>> parameters to existing functions for improved substring handling in PHP:
>>
>> https://wiki.php.net/rfc/working_with_substrings
> 
> 
> Hi Thomas,
> 
> Thanks for your effort on this, I think efficient string handling 
> functions would be a major help for the ecosystem, allowing library 
> authors to do things in plain PHP code which currently defer to C 
> extensions just for performance.
> 
> 
> My first thought opening the RFC was to see a function signature with 9 
> arguments and immediately wonder how to refactor it into something more 
> manageable. Just writing *tests* for all the combinations sounds like a 
> nightmare, let alone understanding code that uses them all.

I agree with and understand this sentiment.


> As I read through, I had a similar feeling about the need to 
> copy-and-paste the same two parameters onto so many functions.
> 
> 
> Luckily, I think the RFC contains the seed of the solution to both 
> problems: what you refer to as "virtual buffers". These seem to be 
> crying out to be a new data type, with their own API - probably using OO 
> style, given general fashions.

I thought about that but didn't know how well it would be received nor, 
perhaps more importantly, the direction it should take (i.e. a formal 
Zend type in the engine, extending the existing zend_string type, a 
class, some combination, or something else entirely).  All of the more 
advanced options I came up with would have required some code changes to 
the PHP source itself with a new data type being the most involved and 
probably the most controversial.

As a result, I ended up deciding to go the "simple" function(s) route in 
the qolfuncs extension and then, after that, use the RFC process to 
kickstart the conversation while also showing a proof-of-concept that 
demonstrates performance can be notably improved in certain areas that 
have traditionally not done well.  I figured it would be kind of 
difficult to get folks excited about strings/buffers (yawn!) if there 
weren't also some sort of ballpark in-context metrics/benchmarks to show 
the potential gains to make the effort worthwhile.


> Framed around that, I think we can split out a few different concerns:
> 
> * Methods to take a string, and make a new, writeable buffer pointing at 
> all or part of it
> * Methods to access parts of a buffer, as a string or another buffer
> * Methods to efficiently write to, delete from, or overwrite, parts of a 
> buffer
> * Methods to explicitly manage the memory used by the buffer
> * Finally, support for writing to, or reading from, a buffer instead of 
> a string in a number of existing functions

Those sound fine.  Just a couple thoughts:

Being able to pass a new buffer type around to many of the same 
functions as zend_strings could introduce its own can of worms. 
Something to keep in mind for sure.

Calling any function/method in PHP is an "expensive" operation.  Once 
the code finally gets into the function body and past the input 
validation phase is when performant C routine calls can finally happen 
(e.g. native memcpy/memmove/memset calls that, in turn, use SIMD 
instructions).  It's all the prior setup that takes the longest amount 
of time.  I don't think there's a way around that without losing buffer 
overflow protections, which means there will ultimately always be a hard 
upper limit on what can be done in PHP userland.  But we at least now 
know the userland performance ceiling for inline buffer manipulation is 
somewhere roughly around 2-3 times higher than current userland options 
on average.  Based on the benchmarks I've run, that gain largely negates 
the function/method call overhead problem for the immediate future.


> Thinking about exactly what those methods should look like leads me to 
> my next thought: we should be learning from prior art here. Are there 
> other languages which already do this well, which PHP could emulate? Are 
> there other languages which already do this *badly*, whose mistakes PHP 
> could explicitly learn from?
> 
> What comes to my mind immediately is that both Java and C# have 
> "StringBuilder" classes, which cover at least some of these use cases. 
> C#, in particular, had a lot of very smart people paid to design it, 
> able to learn from mistakes Java had already made.

Okay.


I'm not entirely sure what the next step here should be.  Should I go 
research the above, or go back and develop/test and then propose 
something concrete in an OO direction and gather feedback at that point, 
or should we hash it out a bit more here on the list to get a more 
specific direction to go in?

Regardless, I've updated the RFC to reflect your response as Open Issue 
9.  Thank you for taking the time to look at the RFC and responding.

-- 
Thomas Hruska
CubicleSoft President

CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.

What software are you looking to build?