Though this does limit the problem, it doesn't eliminate it. After looking at implementations I decided to troll through blog entries. I figured that people having a common problem would blog about them. What I found was pretty much what I expected to find. There were a lot of blogs that talked about how to improve network performance. There was also a smaller number of blogs that talked about execution performance (read CPU utilization). The smallest number of entries related to memory utilization. The biggest non-surprise were the large numbers of bad micro-performance benchmarks or questionable bits of performance advice.
The most interesting observation was the lack of blogs on memory leaks and memory profiling. The blog entries were there. There just wasn't many of them and there is probably a good reason why. Browsers are up and down more often then elevators in an office building at lunch time. Every time the browser exits, away goes the memory leak. Memory leaks are really only problematic in a process that stays up for a long time. I once left Firefox up for more than 2 weeks and it was very apparent that some pages that I was visiting leaked memory very badly. I finally had to restart the browser because it stopped responding in a reasonable amount of time. While this fix is quite ok in a client, it's not so well liked for serverside work.
Figure 1. Cycles in an Object Graph
All in all the experience was interesting. I got to look at a couple of new tools, Firebug and YSlow (Yahoo). There wasn't any real surprises. Network calls and servers were the primary culprit of poor performance, testing clients is still a pain and our old and reliable performance tuning methodology worked.