Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46711
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain wikimedia.org from 66.111.4.26 cause and error)
Message-ID: <4B4E5943.3000706@wikimedia.org>
Date: Thu, 14 Jan 2010 10:37:39 +1100
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: 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>
In-Reply-To: <4B4DFBDE.1020906@lerdorf.com>
OpenPGP: id=BF976370
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] About optimization
From: tstarling@wikimedia.org (Tim Starling)

Rasmus Lerdorf wrote:
> Tim Starling wrote:
>   
>> 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
>> not much less. A simple object (due to being based on the same
>> inefficient data structure) may use a kilobyte or two.
>>     
>
> A zval is around 64 bytes.  So, to use 200 bytes per string element,
> each of your strings must be around 136 chars long.
>   

<?php
$m = memory_get_usage();
$a = explode(',', str_repeat(',', 100000));
print (memory_get_usage() - $m)/100000;
?>

I get 197 on 32-bit and 259 on 64-bit. Try it for yourself if you don't
believe me. I've cross-checked memory_get_usage() against "ps -o rss",
it's pretty accurate.

> For me, working in super high-load environments, this was never an issue
> because memory was always way more plentiful than cpu.  You can only
> slice a cpu in so many slices.  Even if you could run 1024 concurrent
> Apache/PHP processes, you wouldn't want to unless you could somehow
> shove 64 cpus into your machine.  For high-performance high-load
> environments you want to get each request serviced as fast as possible
> and attempting to handle too many concurrent requests works against you
> here.
>   

Maybe the tasks you do are usually with small data sets.

-- Tim Starling