Hi Sara, > -----Original Message----- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 17, 2007 11:36 PM > To: Dmitry Stogov > Cc: internals@lists.php.net; Andrei Zmievski; Andi Gutmans > Subject: Re: [PHP-DEV] Giving Globals the CV treatment [WAS: > Runtime JIT Proposals] > > > > It is interesting and very clear patch. > > Probably you idea can be extended to support regular globals too. I > > mean $GLOBALS["name"]. > > > GLOBALS is itself in the auto global registry, so these would > automatically get picked up too. Oh, no, you probably mean > have that > entire expression boil down to a CV, ah... that'll be > slightly tricker > (since it'll involve rewriting the opcode), but in principle it > shouldn't be impossible. Even if it's ugly to do in the single-pass > compiler, an opcode optimizer could certainly handle it in its second > pass once the fetch_type is added to CV definitions... > > > BTW I am not sure this patch will give significant speedup, because > > locals are used most often then globals, and your patch adds small > > overhead for them. Did you benchmarked your patch? > > > Well, I gave it the usual BogoMIPS treatment (Bogus Meaningless > Indication of Processor Speed for anyone who doesn't recognize that), > and I got the following encouraging numbers: > > <?php > $_POST['foo'] = 'bar'; > > for($i = 0; $i<1000000; $i++) > $b = $_POST['foo']; > ?> > > [current -- without patch] > $ time sapi/cli/php -f test.php > real 0m1.057s > user 0m0.660s > sys 0m0.000s > > > [with patch] > $ time sapi/cli/php -f test.php > real 0m0.490s > user 0m0.467s > sys 0m0.000s > > Even looking at just the user times, the gain is in the right > direction > and is a fair percentage...
So your patch makes sense. Could you also run Zend/bench.php to check that patch doesn't slowdown local fetches. I think the patch can be commited into HEAD (not into PHP_5_2), but I would prefer collect all performance patches and commit them into PHP_5_3 and HEAD together. > > According to ZEND_BEGIN_SILENCE, just try to run simple > script <?php > > $x = @$y;?> with and without this check. In case of missing check, > > real $y fetch is performed in ASSIGN operator after > ZEND_END_SILENCE, > > so we see error message. > > > Ah, of course, that makes perfect sense... And I've got to > say, that's > a clever solution to that problem. It does unnecessarily rob DIM/OBJ > fetches in a localized silence ($foo = @$bar[$baz];) of being CV when > those technically could, but that's a fairly small price to > pay for the > elegance of the solution. I would be glad to look into another solution, but I cannot even imagine it. PHP language wasn't designed to be fast :( > So leaving the silence alone (since it's necessary), and > considering the > appearant gain for a minor code change, what are your thoughts on > tossing this in as is and looking at extending it for > $GLOBALS['foo'] -> > (global fetch CV)$foo later on? Agree. See above. Dmitry. > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
