Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85747
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nH6D3Ot6SBK6KkUbFao8S_KhdGYU=dWjmjc7BvLORL+1Q@mail.gmail.com>
References: <CAAyV7nH6D3Ot6SBK6KkUbFao8S_KhdGYU=dWjmjc7BvLORL+1Q@mail.gmail.com>
Date: Wed, 8 Apr 2015 23:55:26 +0300
Message-ID: <CA+9eiLuaNd=QoUm8=2g6fjK555ejr48aKtiBCyXynwf2kot+6A@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113403822ecc4d05133cc080
Subject: Re: [PHP-DEV] Concern around growing complexity in engine - hash
 table specifically
From: dmitry@zend.com (Dmitry Stogov)

--001a113403822ecc4d05133cc080
Content-Type: text/plain; charset=UTF-8

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
>
>

--001a113403822ecc4d05133cc080--