Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74158
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.128.174 cause and error)
References: <e5f19ac0089d24adc695fce93ad9bd9c.squirrel@webmail.klapt.com>
	<CA+9eiLuoJM5bwA46M_2YddTXYOhAwhii=9Ref7-NNeuRuBfW5A@mail.gmail.com>
	<CAEZPtU7zz=npjUhacwSBA6cz+kb9iBmn3fjkvYuAjqtiPQgJhw@mail.gmail.com> <CAF+90c9J5mtTzqFxvQHka5w5zVoGOzXNaUeYec62X_LYLOPcxA@mail.gmail.com>
In-Reply-To: <CAF+90c9J5mtTzqFxvQHka5w5zVoGOzXNaUeYec62X_LYLOPcxA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQC7HuE3UTXSihebCHoftrMU80C7TANQnU43APB9DS4CfHO5+50yZWcA
Date: Wed, 14 May 2014 00:52:41 -0700
Message-ID: <db6f4b4c2d10f343d4c30ee66d82b0eb@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: zeev@zend.com (Zeev Suraski)

Well put Nikita!

Guys - we're in a bit of a ridiculous situation where the key low-level
engine maintainers are saying this patch is unacceptable, yet it may pass
due to the low level of overall interest and the lack of special rules to
govern low-level changes like that (where with all due respect, I think the
main maintainers of the engine should get much stronger power).

The patch the way it is now should be discarded;  All the macro changes, as
well as any data structure change except for IS_LONG should be removed.

Given that the current RFC doesn't thoroughly represent the performance hit
(in terms of memory footprint, as well as resulting performance hit -
especially when using phpng), I recommend the following:

* Add the relevant performance feedback from Dmitry to the RFC, as well as
his concerns as the chief performance guy php.net has
* Provide an option for people to vote 'yes' for the IS_LONG size part only

If the authors of the RFC object, my request from everyone who has voting
rights here is to vote 'no' and we can create a separate RFC for the IS_LONG
part only.  Forcing this change against the explicit concerns of Dmitry and
Nikita, who worked their rear ends off to squeeze every bit of performance
in phpng (along with Xinchen, and now others joining in) - is, well,
ridiculous IMHO.

Zeev

> Sorry, what did I miss here? Why cannot the phpng numbers be taken as
> "valid"?
> The very same issue also exists in our current implementation. In phpng
> the
> relative hit is just larger, because the structures are more optimized.
>
> I think you shouldn't dismiss Dmitry's point just like that. Having
> support for 64
> bit integers on Windows and other LLP64 architectures - that's great.
> Making
> string lengths unsigned - that's great as well. But supporting strings
> larger than
> 4G or arrays with more than 4 billion elements - that does not seem very
> useful
> and unlike the other two changes, hurts memory usage. I wonder how many
> people would prefer having lower memory usage over having the ability to
> create arrays with 4 billion elements.
>
> Independently of that: In a lot of the previous discussion people have
> many,
> many, many times asked that this patch be implemented without all those
> macros renames and zpp changes. I still have a hard time seeing the
> benefit of
> doing that. The zpp changes also conflict with phpng, because S has a
> different
> meaning (and imho for no good reason - it could just as well stay at s).
>
> Nikita