Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46741
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.117 as permitted sender)
Message-ID: <4B4FA41E.2090703@zend.com>
Date: Thu, 14 Jan 2010 15:09:18 -0800
Organization: Zend Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0
MIME-Version: 1.0
To: Tim Starling <tstarling@wikimedia.org>
CC: internals@lists.php.net
References: <4B4DABED.4060202@easyflirt.com> <hikb2l$q54$1@ger.gmane.org> 	<4B4DBF40.5040801@easyflirt.com> <4B4DCFDA.6090206@dmi.me.uk> <e382ba1001130725k5095fcdcqb305d7b5043b70e8@mail.gmail.com> <4B4DF01A.1080103@wikimedia.org> <4B4DFBDE.1020906@lerdorf.com> <4B4E5943.3000706@wikimedia.org> <4B4E5D5B.9020805@zend.com> <4B4E6BE5.1070404@wikimedia.org> <4B4E79A6.2010904@zend.com> <4B4E8D15.60508@wikimedia.org>
In-Reply-To: <4B4E8D15.60508@wikimedia.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] About optimization
From: stas@zend.com (Stanislav Malyshev)

Hi!

> Basically a structure like the current zend_op_array would be created on
> demand by the executor instead of in advance by the compiler.

I guess we could have strings, etc. put in one big string buffer and 
refer to them by 32-bit index, that would probably work with statically 
allocated things (like filenames, etc.) But that'd only be useful in 
64-bit case, and would just slow down 32-bit (since we probably couldn't 
afford having 16-bit indexes), which means we should either have 
separate code for 32 and 64 or have a ton of macros for each string 
access. I'm not sure that is worth the trouble.

We could do something that could improve things somewhat - namely, 
organize all static strings into per-op-array string table (in op_array 
and znode zvals) and refer to them by index. That also would give us 
some advantages since we could precalculate hashes. IIRC Dmitry Stogov 
had done some research on that.

> You can do it with a length field and a char[1] at the end of the
> structure. When you allocate memory for the structure, you add some on
> for the string. Then you copy the string into the char[1], overflowing it.
>
> If you need several strings, then you can have several byte offsets,
> which are added to the start of the char[1] to find the location of the
> string in question. You can make the offset fields small, say 16 bits.

It's definitely be too much trouble to work with such structures, will 
lead to a ton of bugs and it'd be a nightmare to manage...

> But it's mostly zend_op I'm interested in rather than zend_op_array.
> Currently if a zend_op has a string literal argument, you'd make a zval
> for it and copy it into op1.u.constant. But the zval allocation could be

No, zval is part of znode. There might be an allocation on compile 
stage, etc. but it's temporary - the zval itself is stored inside znode, 
not allocated elsewhere. See zend_compile.h

> avoided. The handler could cast the zend_op to a zend_op_with_a_string,
> which would have a length field and an overflowed char[1] at the end for
> the string argument.

Since we need to address zend_op's inside array, variable size ops would 
be a major inconvenience. Also, since zval is an union, I'm not even 
sure you'll be saving that much. Constant table though might allow some 
savings, but would complicate opcodes somewhat.

> A variable op size would make iterating through zend_op_array.opcodes
> would be slightly more awkward, something like:

Note that we need not just iterating but also random access (and no, not 
only for goto :) - many constructs are compiled into code including jumps).

BTW, as for more effective vars storage - did you look at SPL types, 
especially SplFixedArray? It looks like exactly what you want with 
fixed-size storage.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com