Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81276
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <CABBJUpcLyY-U1yTVEY86Km-O677rF8MAoTa8OaKRBzeC1nkQew@mail.gmail.com>
References: <20150122103807.DD8255F8EE@mx.zeyon.net> <CA+9eiLvLSK3m1PBfS_WY3dQsxbmBHCQ_X6_gh0ynCdOMSypySA@mail.gmail.com>
 <CABBJUpcLyY-U1yTVEY86Km-O677rF8MAoTa8OaKRBzeC1nkQew@mail.gmail.com>
Date: Wed, 28 Jan 2015 11:27:19 +0800
Message-ID: <CABBJUpecJ05yarzXTOUNnuqJ6sqLeWg+U8hgXv4mMixwddEZRQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Benjamin Coutu <ben.coutu@zeyos.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Improvements to for-each implementation
From: xinchen.h@zend.com (Xinchen Hui)

Hey:

On Wed, Jan 28, 2015 at 11:22 AM, Xinchen Hui <xinchen.h@zend.com> wrote:
> Hey:
>
> On Wed, Jan 28, 2015 at 12:55 AM, Dmitry Stogov <dmitry@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?
I mean, dropping both ZEND_FE_RESET and FE_FETCH share one ZEND_OP_DATA.

the previously example should be:

> 0 FE_RESET
> 1 JMP 3
> 2 ....statements
> 3 FE_FETCH success->2
   4 ZEND_OP_DATA
> 5 ....

thanks
>
> thanks
>
>>
>> Thanks. Dmitry.
>>
>>
>>
>> On Thu, Jan 22, 2015 at 1:38 PM, Benjamin Coutu <ben.coutu@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.ppv@gmail.com>
>>> To: Benjamin Coutu <ben.coutu@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/