Re: Concern around growing complexity in engine - hash table specifically

From: Date: Wed, 08 Apr 2015 20:55:26 +0000
Subject: Re: Concern around growing complexity in engine - hash table specifically
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-85747@lists.php.net to get a copy of this message
On Fri, Apr 3, 2015 at 9:57 PM, Anthony Ferrara <ircmaxell@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 > >

« previous php.internals (#85747) next »