Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95754
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <F4.52.16256.34F1A275@pb1.pair.com>
Message-ID: <9203225f-3367-6f31-7aa7-2a8ef373c858@gmx.de>
Date: Wed, 7 Sep 2016 17:21:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <F4.52.16256.34F1A275@pb1.pair.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: The death of `#ifndef FAST_ZPP`?
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 04.05.2016 at 18:11, Andrea Faulds wrote:

> Since FAST_ZPP was implemented, many functions in built-in PHP
> extensions look like this:
>
> […]
>
> That is, they have /two/ sets of parameter processing code: one using
> the old API, and one using the new API, with conditional compilation.
> This is necessary because it is still possible to turn off FAST_ZPP by
> changing the value of the macro.
> 
> However, should that be the case? The FAST_ZPP RFC was approved and PHP
> 7.0 was released containing it enabled by default, so it's no longer
> just an experimental performance enhancement. 

It seems to me that the FAST_ZPP macro is not (only) to disable an
experimental feature, but rather to be able to reduce the size of the
built binaries.  I've just checked a `./configure --disable-all`:

  with FAST_ZPP:    16,651,912
  without FAST_ZPP: 16,276,152

That's a difference of 375,760 bytes, but only 2% increase.

> Furthermore, I have no
> reason to believe that the option to turn off FAST_ZPP is actually used
> in practice, though feel free to prove me wrong!

Perhaps that is so, because FAST_ZPP can't be turned of via ./configure.

> Requiring all usages of FAST_ZPP to be accompanied by a
> zend_parse_parameters() fallback creates code bloat. It also creates
> hidden, potentially build-breaking bugs, because the code is rarely
> built with FAST_ZPP disabled. It's like the old TSRMLS_CC situation.
> 
> Furthermore, for those who would prefer the FAST_ZPP API, it is
> inconvenient that they cannot use it exclusively and must also use
> zend_parse_parameters(), doubling the effort.

Valid points.

> So, I would like to ask: would there be any objections to going through
> and removing all unnecessary zend_parse_parameters fallbacks, and making
> it impossible to disable FAST_ZPP? This would make the two APIs equally
> valid.

All in all, I think that the benefits of using only one of the parameter
parsing APIs per function outweigh the drawbacks, so I'm +1 on the
removal of the FAST_ZPP macro.

-- 
Christoph M. Becker