Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95755
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5E.70.06456.AB130D75@pb1.pair.com>
To: internals@lists.php.net
References: <F4.52.16256.34F1A275@pb1.pair.com>
 <9203225f-3367-6f31-7aa7-2a8ef373c858@gmx.de>
Date: Wed, 7 Sep 2016 16:26:46 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0)
 Gecko/20100101 Firefox/43.0 SeaMonkey/2.40
MIME-Version: 1.0
In-Reply-To: <9203225f-3367-6f31-7aa7-2a8ef373c858@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: The death of `#ifndef FAST_ZPP`?
From: ajf@ajf.me (Andrea Faulds)

Hi Christoph,

Christoph M. Becker wrote:
> On 04.05.2016 at 18:11, Andrea Faulds wrote:
>
> 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.

This is a fair point. Functions using Fast ZPP have larger code size, 
because of aggressive inlining.

If every function used it, I suppose it might bloat the size of the PHP 
binary somewhat.

>
>> 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.

That's true, but I don't know if there was any reason to add such an option.

In any case, thanks to some uncaught bugs in dead code, no stable 
release of PHP 7 has been able to compile with FAST_ZPP disabled anyway, 
which means I can be certain nobody is using it.

Thanks for your input.

-- 
Andrea Faulds
https://ajf.me/