Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69919 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52367 invoked from network); 28 Oct 2013 18:31:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Oct 2013 18:31:45 -0000 Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender) X-PHP-List-Original-Sender: ab@php.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:45941] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FB/D8-22054-D8DAE625 for ; Mon, 28 Oct 2013 13:31:44 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id B2B7A23D628E; Mon, 28 Oct 2013 19:31:38 +0100 (CET) Received: from 92.75.39.160 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Mon, 28 Oct 2013 19:31:38 +0100 Message-ID: <7c830ad80d33e82eb5f1553d03a44c6d.squirrel@webmail.klapt.com> In-Reply-To: References: <63d89379efdd7f2ba0bcf0b62d5025af.squirrel@webmail.klapt.com> Date: Mon, 28 Oct 2013 19:31:38 +0100 To: "Dmitry Stogov" Cc: "Pierre Joye" , "PHP Internals" , "Andi Gutmans" , "Zeev Suraski" , "Xinchen Hui" Reply-To: "Anatol Belski" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Re: Fix for bug #50333 From: ab@php.net ("Anatol Belski") Hi Dmitry, On Wed, October 23, 2013 14:55, Dmitry Stogov wrote: > Hi Anatol, > > > First of all PHP is mainly used as NTS on Linux (LAMP stack) > It's the reason I tested it first, to check if your patch affects the > performance that is really important for users. > > I still think that tsrm_do_alloca() have to be replaced by do_alloca(). > They have exactly the same logic, except that the first one fallback to > malloc() and the second one to emalloc(). It must not be affected by > malloc()s and realloc()s if you changed them into emalloc() and > erealloc(). May be I missing something... > > > I'm not sure about alloca() usage on Windows, but you may change zend.h > if you like. BTW: I don't think we should replace alloca() by _malloca(), > because do_alloca() already does the same in portable way and uses > per-request heap. > last week I've updated the patch according to your recommendations, now we have the performance test results http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20131025-MasterVanilla-Master50333-3820.html http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20131025-MasterVanilla-Master50333-7795.html Also enabled the stack usage in both TS/NTS for windows. It shows still no improvement as one can see. Though, there are some functions, like virtual_file_ex(), which use emalloc() only in the patch, but called very often within the virtual cwd API. Changing them would require signature changes os one can efree() in case of the fallback situation, but still it's doubtful that would tell some bigger difference in performance. Do you think it's worth a try? Regards Anatol