Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74203 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57441 invoked from network); 14 May 2014 18:16:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 May 2014 18:16:22 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.75 smtp75.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.75] ([108.166.43.75:53546] helo=smtp75.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 65/8E-15285-5F2B3735 for ; Wed, 14 May 2014 14:16:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 81E491E89AA; Wed, 14 May 2014 14:16:18 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 9B8581E881E; Wed, 14 May 2014 14:16:17 -0400 (EDT) Message-ID: <5373B2DE.3090108@sugarcrm.com> Date: Wed, 14 May 2014 11:15:58 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pierre Joye , Nikita Popov CC: Dmitry Stogov , Anatol Belski , PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string length and integer From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > This is a biased argument, you know it, I know it. The key point is > not about the new maximum size of an array or string but the long due > clean and safe 64bit implementation, following well known good > practice (can be seen in almost all other OSS projects out there) and > standards. I personally am still confused about why clean and safe 64-bit implementation requires 64-bit string lengths. > As of now, phpng has been worked on for the last months, totally > privately. And even if it looks promising it is still not remotely > ready to be actually proposed. However it does not prevent you to use > it to stop other improvements, which have been worked on for months, > publically, with continuous tests, status updates, etc. I am not sure > what is happening here is good for PHP. Nobody is proposing to stop other improvements. What people (including myself) are concerned about is that change to 64-bit strings, due to the increase in memory usage, may negate the very perceivable benefits of the phpng and impact performance, all while not being beneficial for 99% of the users. This is something that can not be fixed by saying "phpng is not production quality yet". It is not, but we have an issue here that does not depend on quality of phpng and we need to find a resolution for it. Maybe if we have types cleaned up and compartmentalized, we could have it working with both options and then make a decision based on later performance tests? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227