On Thu, Jan 30, 2014 at 8:16 PM, Stephen Zarkos
<Stephen.Zarkos@microsoft.com> wrote:
> Hi,
>
>
>> -----Original Message-----
>> From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
>> Sent: Thursday, January 30, 2014 7:30 PM
>> To: Stephen Zarkos
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
>> length and integer
>>
>> On Thu, Jan 30, 2014 at 6:59 PM, Stephen Zarkos
>> <Stephen.Zarkos@microsoft.com> wrote:
>> > Hi,
>> >
>> >> -----Original Message-----
>> >> From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
>> >>
>> >> - To the casual observer, the performance stats look great!
>> >> ...But they are a lie. It doesn't matter how 5.5+size_t performs
>> >> since 5.5 isn't the target branch.
>> >> Maybe there have been 5.6 specific performance improvements that
>> >> this patch trashes when merged into 5.6?
>> >
>> > The branch/patch for this RFC is based against the master branch right now,
>> and so that's what was tested against.
>> >
>>
>> Ok. Glad to be wrong. The description should clearly mention that then.
>> And is still wrong, as it compares 5.5.8 against 5.6.0-alpha+size_t then, if I
>> read you correctly?
>>
>
> At this point I'm not really sure what numbers you need. On the RFC there are perf
> results for 5.5.8 and from the str_size_and_int64 branch. We also have results from 5.6.0-a1 on
> w.p.n (same bench, just drop in different PHP versions). Are you saying one must backport the patch
> to 5.5 for you to be satisfied?
Testing the performance implications of this patch compared to 5.5.8
as listed on the wiki makes no sense.
I am saying if you want to publish impact results of this patch then
you must test PHP5.6.0-alpha#1 zts/nts with/without this patch.
Any other comparison is testing apples against melons and melons
against potatoes.
>> I was hoping for yes/no vote - which case I would have voted +1 and we
>> could work on better approach for the extensions in time for the 6.0 release
>> which this clearly is the start of.
>
> Two years from the release of 5.6.0, 5.5 will be EOL and extension developers can just focus on
> compat with 5.6+ and 6.0 (assuming we ever see it). At that time it would be nice IMHO if 5.6+ and
> 6.0 were as similar as possible, starting with this RFC.
>
Lets set away your incorrect fact about "extension developers can just
focus on compat with 5.6+" in 2 years time, and focus on your point:
All extensions have X as lowest supported version, hopefully being 5.6.
That makes sense.
Now remember the fact I wanted everyone to realize and understand:
>> I need people do also understand this little fact:
>> This is how you will create an extension 2years from now.
>> That compat.h header is as important as #include <php.h>
>> Your extension is useless without it.
Just because 5.6 is the "base versions" the extension support, you
will still be using that compat header and workarounds because you, or
anyone else, is not stupid enough to change all these lines of code
for absolutely no gain.
(PHP_NEED_STRSIZE_COMPAT ? "Os|al" : "OS|ai") is the way you will be
passing arguments to zpp from now on.
-Hannes