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. I may also take care about documenting some features in more or less complete form. Thanks. Dmitry. > > > Julien.Pauli >
