[webkit-dev] strategy for evaluating performance issues related to memory.

[Mike Marchywka]

________________________________
> From: lmeyerov at eecs.berkeley.edu
> Date: Tue, 22 Jun 2010 17:51:22 -0700
> To: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] strategy for evaluating performance issues
> related to memory.
>
> I've been doing some memory benchmarking recently (my current interest
> is layout but am also poking at nearby processes). Generally, data
> representation seems hard to usefully tweak in a non-invasive way as
> it's pretty good while being legible (e.g., bit packing), but access
> patterns (and random allocations) already seem questionable. This

fwiw, in some unrelated apps, I actually found that doing seemingly
expensive things and doing them with no regard to efficiency, like a sort on a large data set, 
can quickly pay for itself in  later cache hits. 
In my case anyway it stopped VM thrashing- the original
app continued to act as if data was random but the bash sort result I piped
into it didn't require it to thrash anymore. This turned an impractical runtime into
something quite usable. 

Concise, regular, and local are always better but they may be discarded
due to some initial time to order or compress data or re-order code.



> especially hurts netbooks/mobiles, but I'm seeing high missrates on my
> penryn MacBook Pro and it likely surfaces in the new macbook pros with
> their big L3 but much smaller L2 (though I can't get perf counters w/
> Shark to work there).
>
> A high-impact and less-painful first step might be to target CSS
> selectors & default render style creation:
>
> -- buffer calls at the end of the
> parseToken()->insertNode()->attach()->createRender()->styleForRenderer()->styleForElement()
> pipeline
> -- once enough are in (or there is nothing else to do),
> perform matchRules/matchUARules calls:
> -- in tiles
> -- ... and in parallel
> -- ... and with software prefetching
> -- resume rest of createRender calls (similar tricks may apply, still
> not sure)
>
> A different form of this is now in the firefox mainline but there's
> room to do more using the above (and I suspect with a bit less
> implementation complexity).
>
> Anyways, this seems inappropriate for this list, but if anybody would
> be interested in continuing the discussion, you have my email. Also, if
> there are any resources describing memory layout / instantiation / etc.
> patterns and how/why recomputation/memoization are traded off, it would
> be a nice bootstrap: I've been essentially walking
> through http://webkit.org/blog/114/webcore-rendering-i-the-basics/,

Cool, sorry I just got around to reading this the other day :)
Where do you suggest discussing this? Informal ad hoc mail group?
If you are forming a list obviously add me to it. 

I guess everytime I see coding style issues come up, I keep
thinking about structured comments ( annotations related to this isue.
That is, sure you can keep profiling it and taking tools
to it, and empirical data is always needed, but I keep
thinking that generally each contributor knows how he calculates
the size of each memory allocation and generally how that blob
will be read or written. If there was a concise way to desribe
this to others that may help. Thoughts? I'd like to grep
the code for some comment about memory needs and see if patterns
emerge or see if it suggests to me some place to dig in.

To hijack the thread and wander around in idea space, are there
accepted terms like "todo" or "kluge" to put into comments
so they are easily found or do these things normally end up in 
bug tracker or issue list? 







>
> Regards,
>
> - Leo
>
>
>
>
> On Jun 21, 2010, at 9:05 PM, Maciej Stachowiak wrote:
>
>
> 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> _______________________________________________ webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev