Re: phpng: Refactored PHP Engine with Big Performance Improvement

From: Date: Tue, 06 May 2014 04:19:52 +0000
Subject: Re: phpng: Refactored PHP Engine with Big Performance Improvement
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Tue, May 6, 2014 at 1:44 AM, Dmitry Stogov <[email protected]> wrote:

> ZTS wasn't in our priority list, but Nikita made it more or less work.

Why  do I have a deja vu feeling? ;)


>> Also one thing is totally missing, and is also caused by something
>> that becomes a common case, the 64bit support as it should be has been
>> totally ignored. That makes Anatol work to keep the 64bit branch
>> almost useless. My take on it is that we should either:
>>
>>
>> - move your patch to this branch and then merge to master
>> - merge the 64bit branche then this patch
>
>
> I afraid both ways aren't going to be simple.

Rght, but again, I really do not feel comfortable to ask Anatal or my
team to redo all the work. This would be very bad.

> Anyway, I think 64-bit integer support on Windows64 makes full sense and
> it's possible to add it into "phpng" right now.

Again, it is by far not only a windows change, even if Windows is the
platform with the most visible change from a user point of  view.

> I'm not so sure about size_t string length.

It is hardly imaginable to release php 6 with strings length still
using integer. The memory consumption has been shown to be minimal
during the discussions about the 64bit support. Or did I miss some
important new information?

> I understand your opinion, but when we started this project we didn't know
> if we will get any useful results at all.
> You know, I can't ask everyone in PHP community to freeze development and
> wait while we are thinking :)

No, but it is possible to get a branch and work on it, sync it with
the  other relevant branch. That is what we have done for the 64bit
branch, providing updated builds and tests results while working on
it. Everyone can test it or contribute. This is the way to do such
things from a technical point of view. It is also the way to do it
from a cooperation point of view, for the reasons I gave earlier.


>> I am not sure how to change that or make developers being more open
>> and stopped hidden developments. Any ideas or thoughts on this topic
>> are welcome. It is critical and vital for php, a must do.
>
>
> I don't see problem in hidden development. The formed ideas come as RFC with
> patches.

Well, I do when it comes to such massive changes, no matter how
positive they are. It is all about being open and transparent. Early
participation eases the understanding of the changes, design or
debugging of the new features or changes. This reduces the bus factor
when it comes to maintain it and we both know that this has been an
issue for too long for everything around the engine area.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org


Thread (123 messages)

« previous php.internals (#73930) next »