Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86486 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60810 invoked from network); 4 Jun 2015 09:01:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jun 2015 09:01:23 -0000 Authentication-Results: pb1.pair.com smtp.mail=dev@mabe.berlin; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=dev@mabe.berlin; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error) X-PHP-List-Original-Sender: dev@mabe.berlin X-Host-Fingerprint: 80.237.132.167 wp160.webpack.hosteurope.de Received: from [80.237.132.167] ([80.237.132.167:56875] helo=wp160.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DE/92-32964-2E310755 for ; Thu, 04 Jun 2015 05:01:23 -0400 Received: from dslb-178-000-147-234.178.000.pools.vodafone-ip.de ([178.0.147.234] helo=[192.168.178.46]); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1Z0R1b-0000Q7-FA; Thu, 04 Jun 2015 11:01:19 +0200 Message-ID: <557013DF.9090708@mabe.berlin> Date: Thu, 04 Jun 2015 11:01:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: internals@lists.php.net References: <556F80CF.40303@moonspot.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;dev@mabe.berlin;1433408482;f15c5eb5; Subject: Re: [PHP-DEV] Method call overhead From: dev@mabe.berlin (Marc Bennewitz) On 06/04/2015 06:35 AM, Yasuo Ohgaki wrote: > Hi Brian, > > On Thu, Jun 4, 2015 at 7:33 AM, Brian Moon wrote: > >> This is a better representation of what you are trying to show. It removes >> all the magic call back stuff that could be adding to the slowness you are >> seeing. In addition, it does not create a new object on every call for the >> object method. Creating a new object is going to explicitly slow things >> down. But, it's not related to the call time. >> >> http://3v4l.org/biM9G >> > This version adds up precision errors because microtime() precision is not > high enough for > the purpose. Since the error is random, it does not affect proportion much > but total > execution time. Following damn code does better job for these kinds of > benchmarks. > > http://3v4l.org/eJK07 > > See the total amount of execution time recorded. > If we really need pure execution time, then it should record "for loop" > execution time > with empty body. -> incl. displaying the time for the loop: http://3v4l.org/1vZJI > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net >