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

2010-08-10 Thread Mike Marchywka
From: lmeye...@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

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

2010-06-22 Thread Mike Marchywka
CC: webkit-dev@lists.webkit.org From: ddkil...@webkit.org Subject: Re: [webkit-dev] strategy for evaluating performance issues related to memory. Date: Mon, 21 Jun 2010 19:44:53 -0700 To: marchy...@hotmail.com On Jun 21, 2010, at 6:21 AM

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

2010-06-22 Thread Leo Meyerovich
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

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

2010-06-21 Thread Mike Marchywka
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) I

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

2010-06-21 Thread Jeremy Orlow
On Mon, Jun 21, 2010 at 2:21 PM, Mike Marchywka marchy...@hotmail.comwrote: 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

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

2010-06-21 Thread Mike Marchywka
From: jor...@chromium.org Date: Mon, 21 Jun 2010 18:22:19 +0100 Subject: Re: [webkit-dev] strategy for evaluating performance issues related to memory. To: marchy...@hotmail.com CC: webkit-dev@lists.webkit.org On Mon, Jun 21, 2010 at 2:21 PM, Mike

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

2010-06-21 Thread Jeremy Orlow
On Mon, Jun 21, 2010 at 7:08 PM, Mike Marchywka marchy...@hotmail.comwrote: 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

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

2010-06-21 Thread Mike Marchywka
From: jor...@chromium.org Date: Mon, 21 Jun 2010 19:41:28 +0100 Subject: Re: [webkit-dev] strategy for evaluating performance issues related to memory. To: marchy...@hotmail.com CC: webkit-dev@lists.webkit.org On Mon, Jun 21, 2010 at 7:08 PM

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

2010-06-21 Thread Jens Alfke
On Jun 21, 2010, at 11:59 AM, Mike Marchywka wrote: 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. I spent a couple of months last year looking at

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

2010-06-21 Thread David Kilzer
On Jun 21, 2010, at 6:21 AM, Mike Marchywka marchy...@hotmail.com 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

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

2010-06-21 Thread Maciej Stachowiak
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