Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27676
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 140.211.166.39 cause and error)
DomainKey-Status: good
DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;
	s=mx; d=php.net;
	h=From:Subject:To:Date;
	b=S3rB/TZudPlji3xPJc3bBsjj+mA4OAUQOyzgA2YqgJ8i69r1KdshIGm64PQMQOOH
	dSuJcKR1kNnkpJKxIBgu8JWN0WkpcUZh1n/WogVrzCTwGELhKxqAIz4uRSzWbCUv
Message-ID: <45BA360B.2060703@php.net>
Date: Fri, 26 Jan 2007 09:10:35 -0800
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
CC:  internals@lists.php.net, 'Andi Gutmans' <andi@zend.com>, 
 'Andrei Zmievski' <andrei@gravitonic.com>,
 Zeev Suraski <zeev@zend.com>, Stanislav Malyshev <stas@zend.com>
References: <45B7BA56.40406@php.net> <000001c74156$c1b49a20$6e02a8c0@thinkpad>
In-Reply-To: <000001c74156$c1b49a20$6e02a8c0@thinkpad>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada
From: pollita@php.net (Sara Golemon)

> I fixed one error in your patch, so now it passes all tests.
> 
Which error?  I notice some changes related to minimizing performance 
impact, but I'm not seeing what I did wrong.  Just curious for my own 
benefit on that one.

> BTW I am against this patch.
> 
Fair enough.

> 1) It adds sloppily built functionality into the core 
Well, you sure know how to sweet-talk a gal.

and slowdowns EACH
> dimension or property fetch both at run-time and compilation-time.  I think
> it is a big cost for $_GET/$_POST encoding-conversion, but it is only my
> opinion.
> 
For disarmed callbacks, it amounts to a vector lookup and a couple 
integer compares, I'd hardly call that a "big cost".  As to armed 
callbacks, well, if they're still armed then they still have some work 
to do.  Refer to prior posts in the thread as to why this work would 
(and should) be deferred.

> 2) It adds pointer to zend_auto_global into zend_compiled_variable. This
> makes troubles for opcode caches - zend_compiled_variable(s) may lay in
> shared memory, so they cannot point to process specific data. I think this
> issue can be fixed using indirect pointer (index).
> 
Excellent point.  That will need to be addressed....

> Why did you reject auto-globals as overloaded arrays?
>
See earlier posts in this thread, such as the one I sent you less than a 
week ago and to which you replied indicating you understood it.

If you thinking breaking BC is preferable to this "sloppy" approach, 
then we can reexamine that.  If you have a better, third approach, which 
solves all of the issues already outlined, then I'd love to hear it.

-Sara