Just as a reference point should someone come across this thread at a
later date, and are interested in how memory usage changes
performance, this was one of the articles I found that does a decent
job, somewhat dated:

What every programmer should know about memory
http://lwn.net/Articles/250967/

You can look at the part about what programmers can do:
http://lwn.net/Articles/255364/

And don't forget about the tools like valgrind and perfctr. Also
oprofile, pagein, pfmon, callgrind.

iam

On Mon, Jan 25, 2010 at 4:59 PM, steve <iamste...@gmail.com> 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.
>
> This is a tremendous insight. No where near my experience. (Neither is
> cheap hosting for individuals). Faster PHP means smaller webfarm, and
> if you pay for that webfarm, then these things matter. At any rate,
> thanks for the long description. And I do notice the nice tone in
> contrast to mine that day. Sigh...
>
>> All I can say on this is, send some patches to the list.  PHP improves 
>> through code.
>
> True, true. But I remember a history of push back to such things, and
> even if now that is no longer the case, the price of political
> engagement is too high (that is, just explaining the stuff, etc).
> We're at the point of migrating away (in small tiny steps) anyhow, but
> I hope others that have experience and extra manpower speak up. There
> are some interesting internal forks of php out there that are cleaner
> and faster than what we could contribute anyhow.
>
>> It seems that you did not look closely to the improvements made to PHP 5.3.
>
> Sadly, I'm not sure 5.3 is in the cards for this year, and the stock
> build wouldn't do. Needs work on method dispatch.
>
> iamstever
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to