Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85759
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuQ4Frb-p5KVS3b1kPMPWRFss1OWih7Fv4Ct5qY_W-KxnQ@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>
	<CAMUwpuQ4Frb-p5KVS3b1kPMPWRFss1OWih7Fv4Ct5qY_W-KxnQ@mail.gmail.com>
Date: Thu, 9 Apr 2015 11:18:05 -0400
Message-ID: <CAAyV7nGNqzozvkp7--qNz7dJ1q+bCmcbDZDBnkw-R+Q22uf5nA@mail.gmail.com>
To: jpauli <jpauli@php.net>
Cc: internals@lists.php.net, Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=089e013d18b08875ba05134c27f8
Subject: Re: [PHP-DEV] Concern around growing complexity in engine - hash
 table specifically
From: ircmaxell@gmail.com (Anthony Ferrara)

--089e013d18b08875ba05134c27f8
Content-Type: text/plain; charset=UTF-8

Julien,
On Apr 9, 2015 7:52 AM, "Julien Pauli" <jpauli@php.net> wrote:
>
> 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 ?

+1 from me. That would go a long way towards mitigating some of these
issues.

Anthony

--089e013d18b08875ba05134c27f8--