Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14466 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39213 invoked by uid 1010); 1 Feb 2005 10:40:57 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 39198 invoked by uid 1007); 1 Feb 2005 10:40:57 -0000 Message-ID: <20050201104056.39197.qmail@lists.php.net> To: internals@lists.php.net Date: Tue, 01 Feb 2005 11:41:16 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050106 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20050128223155.81436.qmail@lists.php.net> <5.1.0.14.2.20050128145327.04025190@localhost> <20050128233054.9657.qmail@lists.php.net> <20050128234649.27693.qmail@lists.php.net> <20050128235345.42569.qmail@lists.php.net> <20050130193103.63809.qmail@lists.php.net> <20050131182732.84357.qmail@lists.php.net> <20050131211614.84286.qmail@lists.php.net> <20050131222442.61678.qmail@lists.php.net> <28139bc050131200043b9baff@mail.gmail.com> In-Reply-To: <28139bc050131200043b9baff@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 62.131.2.67 Subject: Re: [PHP-DEV] Re: referencing Superglobals with variable variables inside functions From: tularis@php.net ("M. Sokolewicz") AFAICS, it should make every local-variable (non-global) lookup slower. Since it needs to do a lookup in the globals table first. Xuefer Tinys wrote: > $_GET is solved at compile time, which is good, but this make other > variables bad at execution time? > > how much does this patch slow execution down? it's one more hash lookup. > affect speed of $var or $$var? or both? > > > On Mon, 31 Jan 2005 14:24:41 -0800, Sara Golemon wrote: > >>>So in order for ZE to resolve the autoglobals correctly during runtime it >>>has to ask two questions for every *part* of every variable resolution: >> >>"Are >> >>>we checking against the active symbol table? Is the index we're looking >> >>for >> >>>in the autoglobal registry?" If so, replace active_symbol_table with the >>>global symbol_table, otherwise do the lookup as normal. >>> >> >>I knew this statement felt wrong when I wrote it so I dove in and looked at >>the code again....It's not actually necessary to test the what scope we're >>in because of the way the parser is laid out... however it does still add an >>extra hashtable lookup that shouldn't be necessary, so my original position >>stands as is for now. >> >>If someone would like to benchmark the following patch (Or point out any >>fatal flaws in it) I'd be interrested in the results, but even if there's no >>perceptible difference over a million itterations, I'd probably still >>vote -1 on changing it. >> >>-Sara >> >>Index: Zend/zend_execute.c >>=================================================================== >>RCS file: /repository/ZendEngine2/zend_execute.c,v >>retrieving revision 1.692 >>diff -u -r1.692 zend_execute.c >>--- Zend/zend_execute.c 22 Jan 2005 02:29:18 -0000 1.692 >>+++ Zend/zend_execute.c 31 Jan 2005 22:13:50 -0000 >>@@ -1001,6 +1001,10 @@ >>{ >> switch (opline->op2.u.EA.type) { >> case ZEND_FETCH_LOCAL: >>+ if (zend_hash_exists(CG(auto_globals), >>variable->value.str.val, variable->value.str.len + 1)) { >>+ /* Dynamically resolved auto global */ >>+ return &EG(symbol_table); >>+ } >> return EG(active_symbol_table); >> break; >> case ZEND_FETCH_GLOBAL: >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php >> >>