Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.210.192 cause and error)
Message-ID: <4B5BDA19.5010200@lerdorf.com>
Date: Sat, 23 Jan 2010 21:26:49 -0800
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Tim Starling <tstarling@wikimedia.org>
CC: PHP internals <internals@lists.php.net>
References: <4B4DABED.4060202@easyflirt.com> <4B4DFBDE.1020906@lerdorf.com>	 <4B4E5943.3000706@wikimedia.org> <4B4E5D5B.9020805@zend.com>	 <4B4E6BE5.1070404@wikimedia.org> <4B4E79A6.2010904@zend.com>	 <4B4E8D15.60508@wikimedia.org>	 <57792e851001212136h12d7effaldeb75869808d8350@mail.gmail.com>	 <57792e851001221857m7954ee3ag4485d5cd695b6126@mail.gmail.com>	 <4B5A75B4.1080403@wikimedia.org> <57792e851001231226j5f7e6552s16a7a5aa80e8ea2e@mail.gmail.com> <4B5B6911.2080009@lerdorf.com> <4B5BB438.30906@wikimedia.org>
In-Reply-To: <4B5BB438.30906@wikimedia.org>
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:
> That's not the world I live in. I work on a pure-PHP application which
> is widely used on servers where the installing user does not have the
> ability to change their php.ini or to install extensions or middleware.
> The same application (with a few small extensions in C/C++) is used to
> run one of the largest destinations on the Web. It all works just fine,
> and you sell PHP short when you imply that it can't do this. We're not
> going to fork MediaWiki just because you think it can't be done: it can
> be done and we're doing it.

But aren't the people who have large installs also likely to be running
on something slightly beyond an $10/month shared hosting account?  I bet
a mediawiki extension would be quite popular with the dedicated server
users along with all the slicehost/linode folks who splurge and pay
$40/month for their hosting.

> The original poster suggested an optimisation pass post-compile, which
> obviously doesn't break anything because there's extensions that do it
> already. So I don't know who you're arguing against.

I'm not arguing against anything, simply explaining how we got here.  I
am all for optimizations that don't break everything.  In the case of a
post-compile optimization pass nobody has been able to write one that
could speed up normal code without caching the optimized opcodes.  We do
have pecl/optimizer which works in conjunction with APC.  It can easily
be made to work without APC, but there isn't much point since the pass
always takes longer than the execution time it can save unless the code
being optimized is absolutely horrendous.

We have also played with some of your other ideas in the past, but I
suppose most of the core devs are somewhat spoiled by not needing to run
an entire Wikipedia clone on a $10 shared hosting account.  All I can
say on this is, send some patches to the list.  PHP improves through code.

-Rasmus