Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85751
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.216.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAMUwpuRv08EYHQD35xHXh8-jZveKi-GsSQcGyiWf2F2f36=9sg@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>
Date: Thu, 9 Apr 2015 14:01:19 +0300
Message-ID: <CA+9eiLuQjRLuvVN_Ce5ppOgALHkhxi_NvFYVJyaoYan7kYrcwg@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e016338ee4247470513489198
Subject: Re: [PHP-DEV] Concern around growing complexity in engine - hash
 table specifically
From: dmitry@zend.com (Dmitry Stogov)

--089e016338ee4247470513489198
Content-Type: text/plain; charset=UTF-8

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.
I may also take care about documenting some features in more or less
complete form.

Thanks. Dmitry.



>
>
> Julien.Pauli
>

--089e016338ee4247470513489198--