Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <4B4E79A6.2010904@zend.com>
Date: Wed, 13 Jan 2010 17:55:50 -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>
In-Reply-To: <4B4E6BE5.1070404@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!

> class C {
>      var $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10;
> }
>
> $m = memory_get_usage();
> $a = array();
> for ( $i = 0; $i<  10000; $i++ ) {
>      $a[] = new C;
> }
> print ((memory_get_usage() - $m) / 10000) . "\n";
> ?>
>
> 1927 bytes (I'll use 64-bit from now on since it gives the most shocking
> numbers)

OK, you have object with 10 vars - as we established, vars in array take 
100-200 bytes overhead (depending on bits - 64bits is fatter) so it fits 
the pattern.

> Then the object could be stored as a zval[10]. Object member access
> would be implemented by looking up the member name in the class entry
> hashtable and then using the resulting index into the zval[10]. When the
> object is unpacked (say if the user creates or deletes object members at
> runtime), then the object value becomes a hashtable.

That would mean having 2 object types - "packed" and "unpacked" with all 
(most of) operations basically duplicated. However, for objects it's 
easier than for arrays since objects API is more abstract. I'm not sure 
that would improve situation though - a lot of objects are dynamic and 
for those it would mean a penalty when the object is unpacked.
But this can be tested on the current engine (maybe even without 
breaking BC!) and if it gives good results it may be an option.

> Making oplines use a variable amount of memory (like they do in machine
> code) would be a great help.
>
> For declarations, you could pack structures like zend_class_entry and
> zend_function_entry on to the end of the opline, and access them by
> casting the opline to the appropriate opcode-specific type. That would
> save pointers and also allocator overhead.

zend_class_entry is huge, why would you want to put it into the opline? 
And what opline needs static zend_class_entry anyway?

> At the more extreme end of the spectrum, the compiler could produce a
> pointerless oparray, like JVM bytecode. Then when a function is executed
> for the first time, the oparray could be expanded, with pointers added,
> and the result cached. This would reduce memory usage for code which is

opcodes can be cached (bytecode caches do it) but op_array can't really 
be cached between requests because it contains dynamic structures. 
Unlike Java, PHP does full cleanup after each request, which means no 
preserving dynamic data.

I'm not sure how using pointers in op_array in such manner would help 
though - you'd still need to store things like function names, for 
example, and since you need to store it somewhere, you'd also have some 
pointer to this place. Same goes for a bunch of other op_array's 
properties - you'd need to store them somewhere and be able to find 
them, so I don't see how you'd do it without a pointer of some kind 
involved.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com