On Jun 21, 2010, at 11:59 AM, Mike Marchywka wrote: > > I was hardly worried about who does anything as much as what would make sense > to do. I have interest, motivation, > and multiple copies of the code but not a lot of time to waste of bad > approaches. There was a prior discussion > about coding conventions that should be applicable even to those > contemplating a contribution of just browsing > the code, I fail to see how this discussion is less relevant to current and > possible future development concerns. > > If there was some piece of this or a related effort that could be aided by > certain code features that > would seem to be of interest to everyone and it isn't clear which people > would have important thoughts > to contribute ( or I would take it some other place). > > So I take it that now you just have factories and smart pointers and just > make stuff and have it > allocated wherever without further thought? I guess I could do some > profiling my self and empirically > find problems and just assume that no one has specific comments on suspects > or things they have observed > as possible problems.
In my experience with performance work, and specifically in the context of WebKit, I believe the following are useful approaches to reducing memory use: 1) Find and fix memory leaks. There are good tools for this, and memory leaks contribute considerably to memory growth over a long browsing session. Long-term memory growth is a bigger concern than one-time costs or per-page memory that is properly returned to the system. 2) Run memory profiling tools under a significant and realistic workload, such as Mozilla's "membuster" test. We have had great success with this and in particular you can find some good recent memory use improvements from Sam Weinig and Anders Carlsson, among others, if you look at the ChangeLog. 3) Track memory benchmarks regularly, and identify and fix regressions. 4) Run long automated page loads to verify that memory growth stabilizes eventually, rather than continuing to grow without bound. 5) Investigate memory held by caches, and figure out ways to get the same speed benefits with less overall memory use, for example by discarding redundant data or better tuning the cache to hold the items most likely to be reused. 6) Find reproducible cases of non-leak repeatable memory growth, and determine where the extra memory is going. If you are interested in improving WebKit's memory use, I encourage you to consider one or more of the above approaches. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
