Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85715
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
MIME-Version: 1.0
Date: Fri, 3 Apr 2015 14:57:12 -0400
Message-ID: <CAAyV7nH6D3Ot6SBK6KkUbFao8S_KhdGYU=dWjmjc7BvLORL+1Q@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Concern around growing complexity in engine - hash table specifically
From: ircmaxell@gmail.com (Anthony Ferrara)

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...

Thoughts?