Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer
| From: | Johannes Schlüter | Date: | Mon, 19 May 2014 12:21:11 +0000 |
| Subject: | Re: [VOTE] [RFC] 64 bit platform improvements for string length and integer | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-74358@lists.php.net to get a copy of this message | ||
On Sat, 2014-05-17 at 14:15 +0300, Zeev Suraski wrote:
> For the benefit of everyone, this is all from January. Dmitry's,
> Stas's and Nikita's positions in the actual patch in question can be
> found on this thread.
It should be known that I usually won't support Pierre, but the way this
discussion goes is really bad. There was a long debated and quite openly
developed patch. When it was initially proposed form my perspective the
result was "this might be good, timing is bad, we can't put it in 5.6"
Then some who participated in that debate had an idea and implemented,
ignored the existence of the public known work while working on
something contrary and none found the time to (publicly) discuss this.
This is really bad.
On the other side the attempt to push the size_t/int64 thing now looks
like an attempt to push it through now as a reaction, more for
"political" than technical reasons. This is bad, too. (While I
understand how ridiculous it is to first argue "now it is too late for
5.6" and then "oh, now it is too early for PHP.Next" as I'm essentially
doing)
What we as a community (both (engine) maintainers as well as user
communities) have to decide is how much performance loss we are willing
to pay for "clean" and "quality" code and how to find the balance. Maybe
an approach might be not using a single zend_string type everywhere but
have different types lie zend_small_string for usage in opcode members
(class names, function names, .. would almost certainly fit into a
(unsigned) char and are for the most part engine internal so places for
extra range checks should be minimal.
So please, let's try to avoid confrontation and let's try to define our
common goals and then finding a compromise for the technical questions.
johannes
Attachment: [application/pgp-signature] This is a digitally signed message part signature.asc
Attachment: [application/pgp-signature] This is a digitally signed message part signature.asc