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... > The idea was described months ago, then implemented part by part. https://www.mail-archive.com/internals@lists.php.net/msg72362.html Thanks. Dmitry. > > Thoughts? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
