On Thu, Apr 9, 2015 at 1:01 PM, Dmitry Stogov <dmi...@zend.com> wrote:
> > > On Thu, Apr 9, 2015 at 1:35 PM, Julien Pauli <jpa...@php.net> wrote: > >> On Wed, Apr 8, 2015 at 10:55 PM, Dmitry Stogov <dmi...@zend.com> wrote: >> >>> On Fri, Apr 3, 2015 at 9:57 PM, Anthony Ferrara <ircmax...@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
