Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46704 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6234 invoked from network); 13 Jan 2010 16:59:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2010 16:59:17 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.220.227 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.220.227 mail-fx0-f227.google.com Received: from [209.85.220.227] ([209.85.220.227:52209] helo=mail-fx0-f227.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/EA-00773-4EBFD4B4 for ; Wed, 13 Jan 2010 11:59:17 -0500 Received: by fxm27 with SMTP id 27so746699fxm.23 for ; Wed, 13 Jan 2010 08:59:14 -0800 (PST) Received: by 10.223.5.90 with SMTP id 26mr1378244fau.59.1263401953800; Wed, 13 Jan 2010 08:59:13 -0800 (PST) Received: from ?192.168.200.22? (c-98-234-184-167.hsd1.ca.comcast.net [98.234.184.167]) by mx.google.com with ESMTPS id 16sm10894588fxm.0.2010.01.13.08.59.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 08:59:13 -0800 (PST) Message-ID: <4B4DFBDE.1020906@lerdorf.com> Date: Wed, 13 Jan 2010 08:59:10 -0800 User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Tim Starling CC: internals@lists.php.net References: <4B4DABED.4060202@easyflirt.com> <4B4DBF40.5040801@easyflirt.com> <4B4DCFDA.6090206@dmi.me.uk> <4B4DF01A.1080103@wikimedia.org> In-Reply-To: <4B4DF01A.1080103@wikimedia.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] About optimization From: rasmus@lerdorf.com (Rasmus Lerdorf) 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. 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. -Rasmus