Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46877
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: <4B5BB438.30906@wikimedia.org>
Date: Sun, 24 Jan 2010 13:45:12 +1100
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> <4B5B6911.2080009@lerdorf.com>
In-Reply-To: <4B5B6911.2080009@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)

steve wrote:
> Like a founder of a company that sets the corporate culture, don't
> count Rasmus out so easily. Founders earn such power. Until they are
> booted. It is not going to, nor should it, happen here.

I don't think PHP has an Ulrich Drepper or a Linus Torvalds. When I read
this list, I see Rasmus arguing on equal terms with other developers, he
doesn't arrogantly pull rank. I think that's good, because Rasmus is
very conservative, and I think PHP has a lot of potential that he
doesn't see.


Rasmus Lerdorf wrote:
> 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.
>   

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.

It all works beautifully: we have volunteers from the Wikimedia side,
and volunteers from the external installation side, and they work
together to develop features that are usable by both.

The small amount of money Wikimedia has comes mostly from individual
donors interested in seeing Wikipedia continue. It would be imprudent to
spend it all on software development without at least trying to attract
volunteers who, instead of donating money, can donate their time.

> 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.
>
>   

Quite so, but I didn't actually suggest anything which would break
source compatibility with the bulk of extensions.

* I suggested having a vector-like mode for hashtables. This could be
implemented while maintaining compatibility with the usual insert, find
and iteration macros and functions. Only extensions which access the
HashTable structure directly, such as ext/standard/array.c, would need
changes.

* I suggested having a more compact, variable-length zend_op. There are
very few extensions that access zend_op, just things like reflection,
APC and parsekit.

* I suggested compact object storage for objects which have the same set
of member variables as their class declaration. This could probably be
implemented in the default handlers without touching the rest of the code.

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.

-- Tim Starling