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. Julien.Pauli
