________________________________

From: jorlow@chromium.org Date: Mon, 21 Jun 2010 18:22:19 +0100 Subject: Re: [webkit-dev] strategy for evaluating performance issues related to memory. To: marchywka@hotmail.com CC: webkit-dev@lists.webkit.org

On Mon, Jun 21, 2010 at 2:21 PM, Mike Marchywka> wrote:

So where does this stand right now? I hope to actually contribute at some point.

but right now I'm just trying to determine approaches to even finding the problems.

( and yes my disk light still comes on for minutes at a time locking me out of doing antyhing

with iceweasel or firefox)

Yes, you've mentioned your disk light blinking several times now. If you have specific bugs to file against specific projects, I suggest you do that. Repeatedly posting about it on webkit-dev (until now, in unrelated threads) doesn't seem particularly useful.

I honestly think this has become a very big problem in many cases and no one seems to appreciate it. It is simply meant to motivate the rest of the post.

I guess at a gross level it would be nice to know when and why page faults occur

but a more pro-active approach would be to start understanding the memory

needs during design or code examination for other reasons. If there is nothing

better, perhaps people could put in formatted comments about memory needs

and access patterns and various parameters or issues or assumptions that

in the code. I haven't entirely thought this through (duh) and hope to stimulate

a discussion ( actually I'd be happy if someone had a one line answer or link

to an answer but am not that opitmistic).

I would approach this as an addition to finding memory leaks but maybe the

worst offenders will go away if there is less clutter.

This is all fairly hand-wavy. If you have specific problems you've seen, please file bugs. If you want to spend some time investigating these issues, great. But I don't understand why you keep bringing this up. Especially since, as far as I can tell, it only involves situations where WebKit memory is spilling to virtual memory which, AFAIK, is not something anyone has spent time optimizing.

This list has discussed many topics relating to bugs, coding conventions, performance, features, etc. These are not independent issues- presumably coding relates to ease of debug and optimization etc. I'm trying to put together a strategy for digging into the memory issues which everyone seems to agree have been largely ignored. Long before VM becomes a problem, usually you have cache problems so I wouldn't say that is the only issue but certainly the most noticable when it happens. Given that no one seems to have looked at it, it is reasonable for me to be concerned that there won't be many obvious clues in the code. If people are more aware of the possible problems perhaps they could leave comments related to memory usage in various places, as just one hand-waving thought. If I find a bunch of stuff like  "new Widget[x]" what am I suppoed to think about it without knowing where "x" comes from ?

Unless you're actively working on this problem within WebKit, these emails seem out of scope for webkit-dev.

The topic addresses this doesn't it? I would think that outlining a development strategy would be "actively working." I don't expect to dig into the code right now beyond what I have already done but if I could figure out what to do I might be able to make more specific contributions later.

Thanks.

- - - - - -

Mike Marchywka | V.P. Technology

415-264-8477

marchywka@phluant.com

Online Advertising and Analytics for Mobile

http://www.phluant.com

note new address

Mike Marchywka

1975 Village Round

Marietta GA 30064

415-264-8477 (w)<- use this

404-788-1216 (C)<- leave message

989-348-4796 (P)<- emergency only

marchywka@hotmail.com

Note: If I am asking for free stuff, I normally use for hobby/non-profit

information but may use in investment forums, public and private.

Please indicate any concerns if applicable.

_________________________________________________________________

Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.

http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:W...

_______________________________________________

webkit-dev mailing list

webkit-dev@lists.webkit.org

http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID283...

________________________________

From: jorlow@chromium.org Date: Mon, 21 Jun 2010 19:41:28 +0100 Subject: Re: [webkit-dev] strategy for evaluating performance issues related to memory. To: marchywka@hotmail.com CC: webkit-dev@lists.webkit.org

On Mon, Jun 21, 2010 at 7:08 PM, Mike Marchywka> wrote:

...

Unless you're actively working on this problem within WebKit, these emails seem out of scope for webkit-dev.

The topic addresses this doesn't it? I would think that outlining a development strategy would be "actively working."

I don't expect to dig into the code right now beyond what I have already done but if I could figure out

what to do I might be able to make more specific contributions later.

If you're not contributing code and you don't have people interested in following your lead, then no I don't think this is the applicable list. I'm not aware of any WebKit contributor that's twiddling their thumbs trying to find something to work on.

Maybe this topic will rise to the top of a contributors priority queue at some point, in which case I could see a discussion being on topic and useful.

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.

J

_________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:W...

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

________________________________

From: lmeyerov@eecs.berkeley.edu Date: Tue, 22 Jun 2010 17:51:22 -0700 To: webkit-dev@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

----------------------------------------

CC: webkit-dev@lists.webkit.org From: ddkilzer@webkit.org Subject: Re: [webkit-dev] strategy for evaluating performance issues related to memory. Date: Mon, 21 Jun 2010 19:44:53 -0700 To: marchywka@hotmail.com

On Jun 21, 2010, at 6:21 AM, Mike Marchywka wrote:

...

(and yes my disk light still comes on for minutes at a time locking me out of doing antyhing with iceweasel or firefox)

Two things:

1. What hardware platform and O/S are you running a WebKit browser on that still uses a disk light? (Do PC cases still have disk lights? I guess I haven't looked recently.)

I've got a 500Mb laptop with firefox on XP and a 1Gb system running debian with iceweasel.

2. Why do you keep mentioning Iceweasel and Firefox? Those browsers are based on Mozilla's Gecko engine, not WebKit.

Those are what I'm using where I see a problem but it seems just about any apps these days have similar issues. I have no idea how the codes or architectures compare but normally ideas seem to diffuse, code and algorithms get copied, and common problems recur. I wanted to use webkit for some specific things, hope to contribute, and many have mentioned memory issues here too. This is just something I'd like to avoid unless it is already a known non-problem. I guess I could go get Chrome and try it out.

Dave

_________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:W...