On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui <xinche...@zend.com> wrote:
> Hey: > > On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > Hi, > > > > I'm working on call/return sequence optimization. As part of this work > I'm > > minimizing the size of call frame (zend_execute_data) and number of > > read/write operations on call/return. > > > > Could you please take a look into the patch that removes EX(scope) > > https://gist.github.com/dstogov/5ad50d582346385d587e > committed. > All phpt tests are passed, but I'm not completely sure about one line - > > > https://gist.github.com/dstogov/5ad50d582346385d587e#file-ex_scope-05-diff-L193 > > > > On the other hand I can't imagine what it may break. > neither do I. > > > > > Matteo, can you please run your test suites with this patch. > > > > PS: I'm also going to: > > - pack EX(num_args) into reserved space of EX(This) > done. > > - try to get rid of EX(frame_info) > done. > > - try to merge EX(called_scope) and EX(This). Only one of them matters. > > - try to replace zval EX(This) with a pointer to zend_object EX(object) > > Hmm, EX(This) is not like EX(object), it will be accessed by vm > handler: get_obj_zval_ptr_unused > > it suppores to return a zval * there. if EX(This) became a zend_object > *, then we may face different handlers for IS_UNUSED and other types > :< > Yes, I know. After the latest changes it doesn't make a lot of sense to replace ZVAL with ZEND_OBJECT*, because other data is already packed into the same ZVAL and it won't save any memory. Also zend_execute_data structure is aligned on zval boundary (16 bytes), so it makes sense to save another 16 bytes, but saving 8 bytes won't affect VM stack memory consumption. Thanks. Dmitry. > > thanks > > > > > Thanks. Dmitry. > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ >
