Hey: On Wed, Jan 28, 2015 at 11:47 AM, Dmitry Stogov <dmi...@zend.com> wrote: > Hi, > > I have this in mind. May be It's even possible to remove JMP. > > FE_RESET op1=<array> op2=<label 2> result=<var> > OP_DATA op1=<iterator> result=<key> > 1: statements... > FE_FETCH op1=<iterator> op2=<label 1> result=<var> > OP_DATA result=<key> > 2: FREE <iterator> > > Anyway, it's not a big problem implementing this, but eliminating of array > duplication is more important. > We still have to solve more serious problems first. > of course, I just was curious maybe this could give us more improvement added to that ~1%.
thanks > Thanks. Dmitry. > > On Wed, Jan 28, 2015 at 6:22 AM, Xinchen Hui <xinche...@zend.com> wrote: >> >> Hey: >> >> On Wed, Jan 28, 2015 at 12:55 AM, Dmitry Stogov <dmi...@zend.com> wrote: >> > Hi, >> > >> > I'm working on a PoC, implementing the proposed behavior - >> > https://gist.github.com/dstogov/a311e8b0b2cabee4dab4 >> > >> > Only few PHPT tests had to be changed to confirm new behavior and >> > actually >> > they started to behave as HHVM. >> > 2 tests are still unfixed XFAILed. Foreach by reference is still need to >> > be >> > improved to support different array modifications. >> > >> > The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and >> > destruction of 200 arrays on each request) >> >> I just have got an idea: >> >> Droping use of ZEND_OP_DATA make it possible to generate better >> foreach loop opcodes >> >> previously FE_RESET and FE_FETCH share one same OP_DATA based on offset. >> >> 0 FE_RESET >> 1 FE_FETCH fail-> 5 >> 2 OP_DATA >> 3 ..... statements >> 4 JMP 1 >> 5.... >> >> without depending on that OP_DATA, we can change this to >> >> 0 FE_RESET >> 1 JMP 3 >> 2 ....statements >> 3 FE_FETCH success->2 >> 4 .... >> >> that will reduce on JMP in every foreach loop >> >> could you please also try this? >> >> thanks >> >> > >> > Thanks. Dmitry. >> > >> > >> > >> > On Thu, Jan 22, 2015 at 1:38 PM, Benjamin Coutu <ben.co...@zeyos.com> >> > wrote: >> >> >> >> Hi Nikita, >> >> >> >> I would suggest using the proposal for the by-value case and sticking >> >> with >> >> the current behavior for the by-reference case as you suggested. >> >> Granted, we >> >> then cannot remove the internal pointer all together, but we would just >> >> use >> >> it for the less common by-reference case as well as for the legacy >> >> reset/next functions, of course. This would still improve most for-each >> >> traversals. At least we then wouldn't have to find a replacement >> >> solution >> >> for rest/prev/next/end. Moreover we can then move the internal position >> >> pointer out of the hashtable structure into zend_array because it is >> >> only >> >> used for userland arrays, not other hash tables (such as object >> >> properties >> >> or internal structures that build upon the hashtable struct). >> >> >> >> Thanks, >> >> >> >> Ben >> >> >> >> ========== Original ========== >> >> From: Nikita Popov <nikita....@gmail.com> >> >> To: Benjamin Coutu <ben.co...@zeyos.com> >> >> Date: Thu, 22 Jan 2015 10:53:19 +0100 >> >> Subject: Re: [PHP-DEV] Improvements to for-each implementation >> >> >> >> Doing this was the idea I had in mind as well, i.e. change the >> >> semantics >> >> of >> >> foreach to say that it will always work on a copy for by-value >> >> iteration >> >> (which ironically avoids having to actually copy it). Note that this >> >> will >> >> differ from the current behavior in a number of ways. In particular it >> >> means that changes to arrays that were references prior to iteration >> >> will >> >> not influence the iteration. >> >> >> >> The real question is what we should do in the by-reference case. Given >> >> that >> >> we need to acquire references to elements of the original array we >> >> can't >> >> reasonably work with copy-semantics (at least I don't see how). So >> >> would >> >> we >> >> just stick with the previous behavior (using the hash position hack) >> >> for >> >> that? >> >> >> >> Nikita >> >> >> >> >> >> -- >> >> PHP Internals - PHP Runtime Development Mailing List >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> > >> >> >> >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ > > -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
