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