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
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