On 5/20/14, 3:35 PM, Yasuo Ohgaki wrote:
> Hi Stas,
>
> On Wed, May 21, 2014 at 6:17 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
>
>>> 64bit int if int is 64bit. I prefer consistency, so array int key is
>> better
>>> to support
>>> 64bit int key. IMHO.
>>
>> Given that 99.9999% of PHP users will never need it, but 100% of PHP
>> users will pay in performance for each size increase, we need to be
>> careful here. "Consistency" is not more magic word than "security".
>>
>>> Similar argument applies to string also. It would be WTF, when users try
>> to
>>> access string offset over 32bit values. Data dealt with PHP is getting
>>> larger
>>> and larger. It would be an issue sooner or later.
>>
>> Not likely, unless somehow PHP becomes language of choice for processing
>> big data. Which I don't see exactly happening. But if it ever happens,
>> we can deal with it then.
>
>
> I think many people don't like PHP and/or switching to other languages are
> concerned
> about consistency as language. Users will just switch tool, so these would
> be issues.
> We just loose users(I mean we loose developers).
>
> I'm really concerned about performance as much as security/consistency like
> you.
> However, average web developers are not. Most developers prefer large and
> slow
> web app frameworks. This is the reality. I think we must face our
> users(developers).
While it is hard to argue with that given the number of large and slow
frameworks out there, there are also many large sites (I have worked for
or helped a bunch of them) that care a *lot* about performance. They
tend to be under-represented both here and in the blogosphere in general
because they don't like to draw attention to any specifics of their
particular technology stacks. Instead they tend to come to me or some of
the other core guys and ask for direct help.
So let's not assume that just because one segment of the userbase
screams the loudest that this segment is representative. We have a large
and diverse userbase and we need to make balanced decisions.
For this particular case of >32-bit string offsets, that would mean that
there is a string in memory that is longer than 4G. It's not like you
can have a sparse string, so you would actually have to fill it beyond
4G. That is an extremely rare use-case and chances are that manipulating
>4G blobs of data is way more efficiently implemented through some sort
of streamed/chunked mechanism as opposed to pulling the entire thing
into memory at once. If we could support it with 0 performance penalty,
ok, but given that there is a penalty we have to weigh the likelihood of
someone needing this in the next 5-8 years against the cost. To me this
is an obvious case that I would balance towards performance.
-Rasmus
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc