Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74160
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <db6f4b4c2d10f343d4c30ee66d82b0eb@mail.gmail.com>
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>
	<db6f4b4c2d10f343d4c30ee66d82b0eb@mail.gmail.com>
Date: Wed, 14 May 2014 10:12:18 +0200
Message-ID: <CAH-PCH7mQkdV=JM0R4zF5-rwMLDmZCrWWqidhZG6TcVdyffgow@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a84d23a784204f957bd76
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a113a84d23a784204f957bd76
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2014 at 9:52 AM, Zeev Suraski <zeev@zend.com> wrote:

> 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 t=
he
> 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 h=
it
> (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 a=
s
> his concerns as the chief performance guy php.net has
> * Provide an option for people to vote 'yes' for the IS_LONG size part on=
ly
>
> 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 a=
nd
> Nikita, who worked their rear ends off to squeeze every bit of performanc=
e
> in phpng (along with Xinchen, and now others joining in) - is, well,
> ridiculous IMHO.
>
> Zeev
>
>
Even though that I agree, that our current voting process is suboptimal,
but I would rather see it fixed instead of ignoring the rules when it is
inconvenient/plain wrong.
What I do think is wrong with the current rfc, is that it states that it
needs only 50%+1 of the votes for acceptance.
The patch is big, it will affect every php installation (eg. not just some
platforms), it changes the Zend Engine, and it requires some non-trivial
effort from the extensions to support it, so even though that the direct
impact on the userland isn't that big (code with long strings etc. which
would fatal will now starts working, big numbers will overflow differently,
etc.) I think it still mandates a 66%+1 vote.

Just my 2 cents.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a113a84d23a784204f957bd76--