Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46712
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: <4B4E5BBC.3080507@zend.com>
Date: Wed, 13 Jan 2010 15:48:12 -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: Graham Kelly <sgkelly4@gmail.com>, Dave Ingram <dave@dmi.me.uk>, 
 "mathieu.suen" <mathieu.suen@easyflirt.com>,
 Sebastian Bergmann <sb@sebastian-bergmann.de>, 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>
In-Reply-To: <4B4DF01A.1080103@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!

> Given this, sometimes it's easy to forget that PHP is pathologically
> memory hungry, to the point of making simple tasks difficult or
> impossible to perform in limited environments. It's the worst language
> I've ever encountered in this respect. An array of small strings will
> use on the order of 200 bytes per element. An array of integers will use

HashTable uses 40 bytes, zval is 16 bytes, Bucket is 36 bytes, which 
means if you use integer indexes, the overhead is 72 bytes per value 
including memory block headers and alignments. It might be too much for 
you, in which case I'd go towards making an extension that creates an 
object storing strings more efficiently and implementing either get/set 
handlers or ArrayAccess (or both). This of course would be most useful 
if you access only small part of strings in each function/method.

I do not see what could be removed from Bucket or zval without hurting 
the functionality.

> not much less. A simple object (due to being based on the same
> inefficient data structure) may use a kilobyte or two.

Kilobyte looks like too much for a single simple object (unless we have 
different notions of simple). Could you describe what exactly makes up 
the kilobyte - what's in the object?

> * Objects that can optionally pack themselves into a class-dependent
> structure and unpack on demand

Objects can do pretty much anything in Zend Engine now, provided you do 
some C :) For the engine, object is basically a pointer and an integer, 
the rest is changeable. Of course, on PHP level we need to have more, 
but that's because certain things just not doable on PHP level. Do you 
have some specific use case that would allow to reduce

> * Exposing strongly-typed list and vector data structures to the user,
> that don't have massive hashtable overheads
> * An oparray format with less 64-bit pointers and more smallish integers

Ah, you're on 64-bit... That explains why your memory requirements is 
larger :) But I'm not sure how the data op array needs can be stored 
without using pointers.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com