Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74380 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64519 invoked from network); 20 May 2014 08:24:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 May 2014 08:24:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.107 smtp107.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.107] ([108.166.43.107:33605] helo=smtp107.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 29/34-34683-5211B735 for ; Tue, 20 May 2014 04:24:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 75E4D9877E for ; Tue, 20 May 2014 04:24:02 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 3A5DF987CD for ; Tue, 20 May 2014 04:24:02 -0400 (EDT) Message-ID: <537B1121.6050107@sugarcrm.com> Date: Tue, 20 May 2014 01:24:01 -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: PHP Internals References: <53755803.2020909@sugarcrm.com> In-Reply-To: <53755803.2020909@sugarcrm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: some phpng benchmarks From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! Following the previous benchmarks post, I've added some benchmarks on the same code for 64-bit patch. For master, I used the official branch, for phpng, the mini-patch here: https://gist.github.com/dstogov/07fcbb60b1b585bcd290 that of course does not represent the whole 64-bit patch but reproduces its most significant effects following the emerging consensus - making zval's string length 64-bit. I have also added memory peak stats both with and without opcache (since opcache doesn't use emalloc it distorts the memory picture a bit). The results are here: https://docs.google.com/spreadsheets/d/1O9gMH_L2rpvFPEVeOOvCmI8Z6-imaIuAw-V9XU19NZI/edit#gid=0 The results suggest that this minimal change - absent any others, and if you believe this very simple and limited benchmark - while producing definite memory increase, beyond margin of error in most cases, is not too bad and at least on this limited example, does not cause performance degradation to the NG patch. Of course, this is only one app and it's not even the real patch but just one (albeit controversial) aspect of it, so we'd need to be careful, but I think this confirms that the consensus proposal (the one Nikita outlined earlier) may be acceptable to go forward. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227