Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
	b=W03k2HEqRr8aTSYcPRPsriX3TKpEBmrjxo5gUOQxF3PwQ8mYZtTP13vsNmeRlqpky1b0Hva1u6YwZRH1gnmwa4KYETnXYPRHTeX+GapdZG2AQC8oGAKK4tVrnWvriGpCCz7d3bJMKqLL/4lf7SgRx92zZPxSjxhUHSbHfh044tI=
Message-ID: <28139bc050131200043b9baff@mail.gmail.com>
Date: Tue, 1 Feb 2005 12:00:37 +0800
Reply-To: Xuefer Tinys <xuefer@gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: internals@lists.php.net
In-Reply-To: <20050131222442.61678.qmail@lists.php.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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>
Subject: Re: [PHP-DEV] Re: referencing Superglobals with variable variables inside functions
From: xuefer@gmail.com (Xuefer Tinys)

$_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 <pollita@php.net> 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
> 
>