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