Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85753
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CA+9eiLuQjRLuvVN_Ce5ppOgALHkhxi_NvFYVJyaoYan7kYrcwg@mail.gmail.com>
References: <CAAyV7nH6D3Ot6SBK6KkUbFao8S_KhdGYU=dWjmjc7BvLORL+1Q@mail.gmail.com>
 <CA+9eiLuaNd=QoUm8=2g6fjK555ejr48aKtiBCyXynwf2kot+6A@mail.gmail.com>
 <CAMUwpuRv08EYHQD35xHXh8-jZveKi-GsSQcGyiWf2F2f36=9sg@mail.gmail.com> <CA+9eiLuQjRLuvVN_Ce5ppOgALHkhxi_NvFYVJyaoYan7kYrcwg@mail.gmail.com>
Date: Thu, 9 Apr 2015 13:52:01 +0200
Message-ID: <CAMUwpuQ4Frb-p5KVS3b1kPMPWRFss1OWih7Fv4Ct5qY_W-KxnQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b5d4e06ff7054051349484c
Subject: Re: [PHP-DEV] Concern around growing complexity in engine - hash
 table specifically
From: jpauli@php.net (Julien Pauli)

--047d7b5d4e06ff7054051349484c
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 9, 2015 at 1:01 PM, Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> On Thu, Apr 9, 2015 at 1:35 PM, Julien Pauli <jpauli@php.net> wrote:
>
>> On Wed, Apr 8, 2015 at 10:55 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>>
>>> On Fri, Apr 3, 2015 at 9:57 PM, Anthony Ferrara <ircmaxell@gmail.com>
>>> wrote:
>>>
>>> > All,
>>> >
>>> > I spent a little bit of time today trying to debug an issue with 7
>>> > that Drupal 8 was facing, specifically regarding an array index not
>>> > behaving correctly ($array["key"] returned null, even though the key
>>> > existed in the hash table).
>>> >
>>> > I noticed that the hash table implementation has gotten orders of
>>> > magnitude more complex in recent times (since phpng was merged).
>>> >
>>> > Specifically, that ardata and arhash are now the same block of memory,
>>> > and that we're now doing negative indexing into arData to get the hash
>>> > map list. From Dmitry's commit message, it was done to keep the data
>>> > that's accessed most often in the same CPU cache line. While I am sure
>>> > that there are definitive performance gains to doing this, I do worry
>>> > about the development and debugging costs of this added complexity.
>>> >
>>> > As well as the way it increases the busfactor of the project.
>>> >
>>> > There is definitely a tradeoff there, as the change is pretty well
>>> > encapsulated behind macros. But that introduces a new level of
>>> > abstraction. But deeper than that it really makes debugging with gdb a
>>> > pain in the neck.
>>> >
>>> > Without hard data on this particular patch, I'm not suggesting we roll
>>> > back the change or anything. I more just want to express concern with
>>> > the trend lately to increase complexity significantly on developers
>>> > for the sake of performance.
>>> >
>>>
>>> > While I'm definitely not saying performance doesn't matter, I also
>>> > think performance at all costs is dangerous. And I wonder if some of
>>> > the more fundamental (even if isolated) changes such as this should be
>>> > way more documented and include the performance justification for
>>> > them. I'm definitely not suggesting an RFC, but perhaps some level of
>>> > discussion should be required for these sorts of changes...
>>> >
>>>
>>>
>> I agree with Anthony.
>>
>> Many things however can be solved with a nice .gdbinit.
>> We already have dump_ht() , dump_htptr() , f.e , that I'm using heavilly
>> to debug HT in PHP5.
>> Not talking about dump_bt().
>>
>> I think one step is to improve our .gdbinit with many more features, and
>> obviously port the actual ones to work with PHP7.
>>
>> A second step is documentation.
>>
>> Anthony, you know about our project phpinternalsbook.com, don't you ;-)
>> There has been recent discussions on IRC to actually merge this project
>> under php.net.
>>
>> I'm really feeling enthusiast about helping or even taking the lead of
>> such a project : I would like php.net to hold a real, detailed
>> documentation about internals.
>>
>> I think with PHP7 should come an internal documentation, somewhere behind
>> php.net , that will explain to a C-aware developper our main internal
>> structures and choices, especially about performance optimisations.
>>
>> Have you had a look at the new Zend Memory Manager ? It has become
>> insanely complex, with many performance-turned code.
>> Same, but in a lower footprint, for the executor : the executor stack
>> frame has really changed from PHP5's one, and is also not very easy to
>> debug (with a long alloced buffer shrinked with many pointer tricks that
>> needs you to have a complete image of the memory buffer in your head).
>>
>> I won't be able myself to document all those tricks, because I'm not the
>> author of them.
>> I think Zend, through Dmitry, Nikic, Bob or Laruence , should help us
>> understanding some concepts, if they are not around to help with the doc.
>>
>
> Hi Julien,
>
> It would be great, if you lead PHP-7 internals documentation project.
> You are always welcome with questions about implementation details.
>

Yes I know that you - as well as other guys I talked about in my last post
- are really open and answer quickly and efficiently to our technical
questions, which is a nice point.

I'm OK to take the lead of such a project.
However, as PHP itself, the project should stay wide open and everyone may
have something to say/bring.

Perhaps time to start a thread about this ?

Julien.P

--047d7b5d4e06ff7054051349484c--