Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85750
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CA+9eiLuaNd=QoUm8=2g6fjK555ejr48aKtiBCyXynwf2kot+6A@mail.gmail.com>
References: <CAAyV7nH6D3Ot6SBK6KkUbFao8S_KhdGYU=dWjmjc7BvLORL+1Q@mail.gmail.com>
 <CA+9eiLuaNd=QoUm8=2g6fjK555ejr48aKtiBCyXynwf2kot+6A@mail.gmail.com>
Date: Thu, 9 Apr 2015 12:35:43 +0200
Message-ID: <CAMUwpuRv08EYHQD35xHXh8-jZveKi-GsSQcGyiWf2F2f36=9sg@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=f46d04447f8320720b051348384c
Subject: Re: [PHP-DEV] Concern around growing complexity in engine - hash
 table specifically
From: jpauli@php.net (Julien Pauli)

--f46d04447f8320720b051348384c
Content-Type: text/plain; charset=UTF-8

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.


Julien.Pauli

--f46d04447f8320720b051348384c--