Re: About optimization -- What every programmer should know about memory

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 >