Re: on memory usage with the 64bit patch, and interpretation of various numbers

From: Date: Fri, 16 May 2014 05:25:46 +0000
Subject: Re: on memory usage with the 64bit patch, and interpretation of various numbers
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-74247@lists.php.net to get a copy of this message
Am 16.05.2014 05:31, schrieb Pierre Joye: > Hi Stas, > > On Fri, May 16, 2014 at 12:03 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: >> Hi! >> >>> ### It's The Correct Data Type >>> >>> The C89 spec indicates in 3.3.3.4 ( >>> >>> http://port70.net/~nsz/c/c89/rationale/c3.html#size-95t-3-3-3-4 ) >>> that >>> the size_t type was created specifically for usage in this context. It >>> is always, 100% guaranteed to be able to hold the bounds of every >>> possible array element. Strings in C are simply char arrays. >> >> Here is my problem with it - we don't need a type that allows to hold >> the bounds of every possible array element. It's like buying a house >> that could contain all your relatives, acquaintances, friends and people >> that you have ever met if they would decide to come to you to stay all >> at once. >> Too expensive and very impractical. We're using unified string >> sizes now, and 99% of the strings we're using never even reach limits of >> 16 bits, let alone come close to limits of int. Carrying around a 64-bit >> value to store that is just waste. We'd be just storing megabytes of >> zeroes without any use. Whatever theoretical reasons there are for >> generic application to use that, they hardly can be applied to very >> specialized and supposed to be highly optimized case as the language >> engine is. It's a fine argument in the generic case, but we do not have >> the generic case here. > > > I wonder if one actually reads it correctly and other replies, but let > me say it again. > > It is a side effect not a goal, at all. Assuming unified behaviour is the #1 goal, the lowest common denominator could be used instead of the largest. The latter obviously has undesired side effects. Ulf

« previous php.internals (#74247) next »