Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9319 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63222 invoked by uid 1010); 17 Apr 2004 09:18:33 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 63187 invoked from network); 17 Apr 2004 09:18:33 -0000 Received: from unknown (HELO alanathome.ossc.com.hk) (202.81.246.113) by pb1.pair.com with SMTP; 17 Apr 2004 09:18:33 -0000 Received: from [192.168.0.40] (helo=akbkhome.com ident=alan) by alanathome.ossc.com.hk with esmtp (Exim 4.24) id 1BEm38-00012e-OH; Sat, 17 Apr 2004 17:23:46 +0800 Message-ID: <4080F6CC.6070804@akbkhome.com> Date: Sat, 17 Apr 2004 17:20:12 +0800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031002 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Garber , internals@lists.php.net References: <5.1.0.14.0.20040417050639.0264ce30@mail.ionzoft.com> In-Reply-To: <5.1.0.14.0.20040417050639.0264ce30@mail.ionzoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC] ifsetor operator From: alan@akbkhome.com (Alan Knowles) if you make @ fetch_var it's own opcode, - on isset() = true you do a straight return value. .. No touching error handler etc.. (this should be v.fast) - on isset() = false you modify the error_handling + do the callback (this is slow...) You have effectively solved the performance issue 99% of the time.... Regards Alan Jason Garber wrote: > Don't forget that some users make use of set_error_handler(). This > results in a user function being called with quite a bit of parameter > data EVEN if an @ is prepended to the statement. The error level is > temporarily set to 0 for the duration of the statement. > > That's why a new internal function addresses the issue so cleanly. > > ~Jason > > > At 4/17/2004 05:03 PM +0800, Alan Knowles wrote: > >> Yeah looks like 50% slower..! >> >> Wouldnt it make more sense to optimize @ + fetch_var(), rather than >> introduce new syntax? >> >> Regards >> Alan >> >> >> Marcus Boerger wrote: >> >>> Hello Alan, >>> Saturday, April 17, 2004, 2:36:55 AM, you wrote: >>> >>>> Jason Garber wrote: >>> >>> >>>>> In our code, you will find many blocks looking like >>>>> >>>>> $CUST_ID = (integer) (isset($_POST['CUST_ID']) ? $_POST['CUST_ID'] >>>>> : 0); >>> >>> >>>> so how is that different from >>>> $CUST_ID = (integer) @$_POST['CUST_ID']; >>> >>> >>> @ is damn slow >> >> >> >> -- >> Can you help out? >> Need Consulting Services or Know of a Job? >> http://www.akbkhome.com >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php > > -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com