Re: Concern around growing complexity in engine - hash table specifically
| From: | Dmitry Stogov | 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
>
>