Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126348
Message-ID: <1b8840b9-5ae0-40db-8af2-521ac5888c7c@bastelstu.be>
Date: Sat, 8 Feb 2025 12:36:25 +0100
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
To: internals@lists.php.net
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
 <5a584219f120385e7e30f6d0a46cc108@bastelstu.be>
 <bd93bbb9-e970-4211-af59-4ccd643dc52f@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <bd93bbb9-e970-4211-af59-4ccd643dc52f@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 2/7/25 22:04, Larry Garfield wrote:
> I split pipes off from the Composition RFC late last night right before posting; I guess I missed a few things while doing so. :-/  Most notably, the Compose section is now removed from pipes, as it is not in scope for this RFC.  (As noted, it's going to be more work so has its own RFC.)  Sorry for the confusion.  I think it should all be handled now.

The “Introduction” section still talks about function composition rather 
than the pipe operator, I believe.

>> 5. The “References” (as in reference variables) section would do well
>> with an example of what doesn't work.
> 
> Example block added.

I don't understand that example. If I would write this as regular 
function calls it works fine. Did you mean to compare against:

     inc_print(['a' => 'A', 'b' => 'B']);

i.e.

     ['a' => 'A', 'b' => 'B'] |> inc_print(...);

? If not, then you will need to expand on “breaks” which is a 
non-technical term.

>> 9. In the “Why in the engine?” section: The RFC makes a claim about
>> performance.
>>
>> Do you have any numbers?
> 
> Not currently.  The statements here are based on simply counting the number of function calls necessary, and PHP function calls are sadly non-cheap.  In previous benchmarks of my own libraries using my Crell/fp library, I did find that the number of function calls involved in some tight pipe operations was both a performance and debugging concern, but I don't have any hard numbers laying about at present to share.
> 
> If you think that's critical, please advise on how to best get meaningful numbers here.

Not sure if I missed the dedicated performance section on my first read 
through the RFC or if it is actually new. It also claims:

 > The result is that pipe has virtually no runtime overhead.

Which given your claim that “function calls are non-cheap” and combined 
with the intermediate closure for calls taking more than one parameter 
is contradictory.

Generally speaking, if your RFC makes a claim (about performance), then 
it needs to back this up by evidence and not with feelings.

Regarding the “How”:

A hyperfine 
(https://tideways.com/profiler/blog/how-we-use-hyperfine-to-measure-php-engine-performance) 
comparison for a release build comparing:

1. An implementation based on regular function calls without 
intermediate variables.
2. An implementation based on regular function calls with an 
intermediate temporary variable.
3. A performance-optimized userland pipe operator implementation.
4. The pipe operator RFC.

would certainly appropriate to gain a first insight.

Having an OPcode dump to compare (1) against (4) would help gain more 
insights as to where the performance differences come from.

> If the expression on the right side that produces a Closure has side effects (output, DB interaction, etc.), then the order in which those side effects happen may change with the different restructuring.

That is a good point. I see you added a precedence section, but this 
does not fully explain the order of operations in face of side-effects 
and more generally with regard to “short-circuiting” behavior. An OPcode 
dump would explain that.

Specifically for:

     function foo()     { echo __FUNCTION__, PHP_EOL; return 1; }
     function bar()     { echo __FUNCTION__, PHP_EOL; return false; }
     function baz($in)  { echo __FUNCTION__, PHP_EOL; return $in; }
     function quux($in) { echo __FUNCTION__, PHP_EOL; return $in; }

     foo()
         |> (bar() ? baz(...) : quux(...))
         |> var_dump(...);

What will the output be?

> but using the temp-var approach makes dealing with references easier

I thought the RFC said that references were disallowed?

Best regards
Tim Düsterhus