Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46876
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.217.218 cause and error)
Message-ID: <4B5B6911.2080009@lerdorf.com>
Date: Sat, 23 Jan 2010 13:24:33 -0800
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: 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>
In-Reply-To: <57792e851001231226j5f7e6552s16a7a5aa80e8ea2e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] About optimization
From: rasmus@lerdorf.com (Rasmus Lerdorf)

I think some of this discussion has been from very different interesting
angles.  Let me explain how I see and use PHP.

PHP is the frontend of your backend.  It is not your backend in any
sizable system.  By that I mean that PHP is not the place to play around
with large data sets.  Databases, Cassandra, Hadoop, memcache, etc.
serve that purpose.  If you need functionality on top of those backend
systems that manipulate millions or even thousands of rows on an
individual request, then you need to build it in something other than
PHP.  It also isn't for forking background processes, hence we have
technologies like Gearman.  PHP punts the hard stuff to technologies
designed to handle those tasks and instead focuses on the glue layers.

In the early days of PHP (1994-1996) I saw PHP as primarily a C API for
extending the web server without needing to know the internal workings
of the web server.  The macro-templating language was a cute feature
that let you expose the functionality you built in C as a set of
template tags.

The Web grew so fast and was initially mostly ignored by lower-level C
developers so the people tasked with building web sites didn't have the
background to write C code against the PHP API which caused the focus to
shift away from the API to bunch of canned tags that people commonly
needed/requested.

This hasn't changed that much over the years.  The templating language
has matured quite a bit and is now powerful enough to write extremely
complicated things in it.  But you still shouldn't write a database in
PHP.

This isn't about server costs.  It is about choosing the right tool for
the right part of the job.  A Javascript library for the client-side
frontend, PHP for the server-side frontend, C/C++ for your middle-layer
and an appropriate datastore behind it all and you can build amazing
things with PHP.  The largest destinations on the Web today are written
exactly like this.

This doesn't mean we shouldn't try to optimize PHP, and you will note
that APC is scheduled to be included in PHP 6, but there is always going
to be significant overhead incurred by a scripting language.  PHP 6
needs more room to store strings, for example, because we live in a
Unicode world.  And yes, there are obviously ways to reduce the overhead
with custom datatypes, but it makes things more complicated because, as
I said, PHP is glue.  By having a single datatype that all the
extensions understand, everything can talk to everything.  Once you
start moving away from the single zval approach towards different
datatypes for different purposes, you have to retrofit all existing
extensions to teach them how to treat these new datatypes and it makes
the already too-complicated extension API even more complicated which
would hurt the glue aspect of PHP.

-Rasmus