Julien, On Apr 9, 2015 7:52 AM, "Julien Pauli" <jpa...@php.net> wrote: > > 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 ?
+1 from me. That would go a long way towards mitigating some of these issues. Anthony
