From the site, it shows the maximum memory usage of Chrome is more than Safari is > 2 times. Since both of them are Webkit base, does that mean the V8 engine uses twice as much memory as squirrel fish?
--- Maximum memory used --- Peak memory usage measured during experiment.
On Sun, Jun 21, 2009 at 12:37 AM, n179911<n179...@gmail.com> wrote: > There is a test which compares memory usage among rendering engines > http://dotnetperls.com/chrome-memory
> From the site, it shows the maximum memory usage of Chrome is more > than Safari is > 2 times.
From TFA:
"Google Chrome posted the highest maximum memory usage ***when all chrome.exe processes were summed***, reaching 1.18 gigabytes, while Firefox posted the lowest maximum memory levels of 327.65 megabytes." [Emphasis mine]
Doing any memory test on a multi-process program where naive summation is used will yield inaccurate results. We wrote a blog post about this problem back when we launched in September:
(I'm not claiming that Google Chrome uses the least memory; I'm just pointing out that the above experiment's methodology is invalid. Calculating actual memory consumption is really hard.)
On Sun, Jun 21, 2009 at 1:25 AM, Elliot Glaysher (Chromium) <
e...@chromium.org> wrote: > "Google Chrome posted the highest maximum memory usage ***when all > chrome.exe processes were summed***, reaching 1.18 gigabytes, while > Firefox posted the lowest maximum memory levels of 327.65 megabytes." > [Emphasis mine]
> Doing any memory test on a multi-process program where naive summation > is used will yield inaccurate results.
I have just mailed the article's author pointing out this flaw and mentioning both the blog post Elliot refers to and our about:memory page.
First off - kudos to the author for posting the source and steps to
reproduce! Most don't do that!
Second, the author is basically right. Since he's running on Vista, its a
bit hard to tell whether his stats included shared memory or not; using the
default memory statistic ("Memory (Private Working Set)") is actually a
pretty good measure to just sum. But he doesn't say which measurement he
used.
I compiled his program and ran it myself (although I only did the first
batch of 30 tabs rather than continuing through 5 iterations). (BTW - his
program was not legal C# syntax and needed slight mods? my version is
attached) I then tested Chrome Single Process mode as well. Two
screenshots are attached with the proof.
The program basically opens up 30 tabs, each with a unique url.
BTW - did we increase the max process limit to 30? I am seeing 30 processes
in use for Chrome in this test.
Normal chrome used 561MB vs Firefox's 146MB.
Single process chrome used 176MB vs Firefox's 153MB.
Overall, I don't think the test is a great test of what users actually do.
But, it is true that Chrome gobbles up far more memory for this test than
other browsers do.
On Sun, Jun 21, 2009 at 9:07 AM, Peter Kasting <pkast...@google.com> wrote:
> On Sun, Jun 21, 2009 at 1:25 AM, Elliot Glaysher (Chromium) <
> e...@chromium.org> wrote:
>> "Google Chrome posted the highest maximum memory usage ***when all
>> chrome.exe processes were summed***, reaching 1.18 gigabytes, while
>> Firefox posted the lowest maximum memory levels of 327.65 megabytes."
>> [Emphasis mine]
>> Doing any memory test on a multi-process program where naive summation
>> is used will yield inaccurate results.
> I have just mailed the article's author pointing out this flaw and
> mentioning both the blog post Elliot refers to and our about:memory page.
> From the site, it shows the maximum memory usage of Chrome is more
> than Safari is > 2 times.
> Since both of them are Webkit base, does that mean the V8 engine uses
> twice as much memory as squirrel fish?
No.
Chrome's multi-process architecture means that each renderer runs in its own
Javascript heap. When you start up any browser, the JS engine will allocate
some amount of memory to its heap. It will garbage collect under some
policy (such as when it reaches certain size limits).
In this case, chrome has 30 processes, and thus 30 javascript heaps. Since
the test just hits home pages, each heap is probably fairly small. If you
wanted to compare Squirrelfish to this test, you'd have to create 30
instances of it :-)
Anyway, if you want to compare V8 to SquirrelFish, there are better ways to
do it (you can take the browser out completely and run tests using each JS
engine's command line shell). You'll find that V8's heap is very compact.
The problem demonstrated in this site's test has more to do with how Chrome
behaves with multiple processes than it does with Javascript. I also think
that the overall performance and reliability benefits of the multi-process
architecture far outweigh the memory impacts. And this test, IMHO, is not
very close to a realistic test of what users do.
I assume he's not a benchmark pro, but he did a decent job already. We can nitpick his sampling methodology - but it won't change the result. He is correct that many procs is far more memory consuming than single proc, and we already knew this. This is a tradeoff we made consciously and deliberately. When firefox crashes, all tabs go down. When firefox memory is compromised (security), all tabs are compromised. In chrome, we don't have those problems, but instead use more RAM. Further, Chrome is also able to implement per-tab prioritization, so that background tabs don't make foreground tabs go slow. Firefox can't do that. Lastly, lets bring the test back to reality. People don't visit 150 random home pages. They may have 20-30 tabs open, but many are applications, with cookies, javascript state and much more than just the "home page". When apps are in use, the memory gap between chrome and FF shrinks a lot.
On Sun, Jun 21, 2009 at 10:46 AM, Dan Kegel <d...@kegel.com> wrote: > On Sun, Jun 21, 2009 at 10:22 AM, Mike Belshe<mbel...@google.com> wrote: > > First off - kudos to the author for posting the source and steps to > > reproduce! Most don't do that!
> > Second, the author is basically right. Since he's running on Vista, its > a > > bit hard to tell whether his stats included shared memory or not; using > the > > default memory statistic ("Memory (Private Working Set)") is actually a > > pretty good measure to just sum. But he doesn't say which measurement he > > used.
> Wait, why doesn't his program itself do the summing? > (I don't see it in there.) > Wouldn't that get rid of the ambiguity? > How hard would it be to add that and repost? > - Dan
> From the site, it shows the maximum memory usage of Chrome is more
> than Safari is > 2 times.
> Since both of them are Webkit base, does that mean the V8 engine uses
> twice as much memory as squirrel fish?
> --- Maximum memory used ---
> Peak memory usage measured during experiment.
>> From the site, it shows the maximum memory usage of Chrome is more
>> than Safari is > 2 times.
>> Since both of them are Webkit base, does that mean the V8 engine uses
>> twice as much memory as squirrel fish?
>> --- Maximum memory used ---
>> Peak memory usage measured during experiment.
On Sun, Jun 21, 2009 at 21:03, Mike Belshe <mbel...@google.com> wrote:
> I assume he's not a benchmark pro, but he did a decent job already. We
> can nitpick his sampling methodology - but it won't change the result. He
> is correct that many procs is far more memory consuming than single proc,
> and we already knew this.
> This is a tradeoff we made consciously and deliberately. When firefox
> crashes, all tabs go down. When firefox memory is compromised (security),
> all tabs are compromised. In chrome, we don't have those problems, but
> instead use more RAM. Further, Chrome is also able to implement per-tab
> prioritization, so that background tabs don't make foreground tabs go slow.
> Firefox can't do that.
> Lastly, lets bring the test back to reality. People don't visit 150 random
> home pages. They may have 20-30 tabs open, but many are applications, with
> cookies, javascript state and much more than just the "home page". When
> apps are in use, the memory gap between chrome and FF shrinks a lot.
> Mike
> On Sun, Jun 21, 2009 at 10:46 AM, Dan Kegel <d...@kegel.com> wrote:
>> On Sun, Jun 21, 2009 at 10:22 AM, Mike Belshe<mbel...@google.com> wrote:
>> > First off - kudos to the author for posting the source and steps to
>> > reproduce! Most don't do that!
>> > Second, the author is basically right. Since he's running on Vista, its
>> a
>> > bit hard to tell whether his stats included shared memory or not; using
>> the
>> > default memory statistic ("Memory (Private Working Set)") is actually a
>> > pretty good measure to just sum. But he doesn't say which measurement
>> he
>> > used.
>> Wait, why doesn't his program itself do the summing?
>> (I don't see it in there.)
>> Wouldn't that get rid of the ambiguity?
>> How hard would it be to add that and repost?
>> - Dan
> On Sun, Jun 21, 2009 at 21:03, Mike Belshe <mbel...@google.com> wrote:
>> I assume he's not a benchmark pro, but he did a decent job already. We
>> can nitpick his sampling methodology - but it won't change the result. He
>> is correct that many procs is far more memory consuming than single proc,
>> and we already knew this.
>> This is a tradeoff we made consciously and deliberately. When firefox
>> crashes, all tabs go down. When firefox memory is compromised (security),
>> all tabs are compromised. In chrome, we don't have those problems, but
>> instead use more RAM. Further, Chrome is also able to implement per-tab
>> prioritization, so that background tabs don't make foreground tabs go slow.
>> Firefox can't do that.
>> Lastly, lets bring the test back to reality. People don't visit 150
>> random home pages. They may have 20-30 tabs open, but many are
>> applications, with cookies, javascript state and much more than just the
>> "home page". When apps are in use, the memory gap between chrome and FF
>> shrinks a lot.
>> Mike
>> On Sun, Jun 21, 2009 at 10:46 AM, Dan Kegel <d...@kegel.com> wrote:
>>> On Sun, Jun 21, 2009 at 10:22 AM, Mike Belshe<mbel...@google.com> wrote:
>>> > First off - kudos to the author for posting the source and steps to
>>> > reproduce! Most don't do that!
>>> > Second, the author is basically right. Since he's running on Vista,
>>> its a
>>> > bit hard to tell whether his stats included shared memory or not; using
>>> the
>>> > default memory statistic ("Memory (Private Working Set)") is actually a
>>> > pretty good measure to just sum. But he doesn't say which measurement
>>> he
>>> > used.
>>> Wait, why doesn't his program itself do the summing?
>>> (I don't see it in there.)
>>> Wouldn't that get rid of the ambiguity?
>>> How hard would it be to add that and repost?
>>> - Dan
> From the site, it shows the maximum memory usage of Chrome is more
> than Safari is > 2 times.
> Since both of them are Webkit base, does that mean the V8 engine uses
> twice as much memory as squirrel fish?
> --- Maximum memory used ---
> Peak memory usage measured during experiment.
I find these results somewhat disingenuous. I left both Firefox and
Chrome open over the weekend (both on Linux, with the Chromium daily
build), Firefox with 1 tab, Chrome with 4 (one of them being Gmail).
Chrome's memory usage didn't move while I had to kill Firefox for
eating up 1.5GB of RAM and being generally unresponsive.
Maybe Chrome uses more memory to do its job initially, but it
certainly doesn't have the leaks that Firefox does which cause me to
have to restart it several times a day. Keep up the awesome work,
Chrome peeps. I can't wait until I'm using Chrome as my default
browser on all my platforms.
I built a web based application in php to upload dvd vob files to a
server via the browser. The only browser that makes this project a non
failure is chrome. Forget trying to upload 4+ gigs with Internet
Explorer. It can not handle the memory addressing. Firefox fails 90%
of the time. However chrome always gets the 4 gigs over the web
interface.
Chrome, an actual browser that doesnt need compatibility buttons, and
also can handle moving 4+gigs with the browser. Chrome is kick ass.
On Jun 22, 12:21 am, PhistucK <phist...@gmail.com> wrote:
> Really? the statistics show that many people are using the app mode?Or did
> you mean web apps, as in web application websites?
> ☆PhistucK
> On Sun, Jun 21, 2009 at 21:03, Mike Belshe <mbel...@google.com> wrote:
> > I assume he's not a benchmark pro, but he did a decent job already. We
> > can nitpick his sampling methodology - but it won't change the result. He
> > is correct that many procs is far more memory consuming than single proc,
> > and we already knew this.
> > This is a tradeoff we made consciously and deliberately. When firefox
> > crashes, all tabs go down. When firefox memory is compromised (security),
> > all tabs are compromised. In chrome, we don't have those problems, but
> > instead use more RAM. Further, Chrome is also able to implement per-tab
> > prioritization, so that background tabs don't make foreground tabs go slow.
> > Firefox can't do that.
> > Lastly, lets bring the test back to reality. People don't visit 150 random
> > home pages. They may have 20-30 tabs open, but many are applications, with
> > cookies, javascript state and much more than just the "home page". When
> > apps are in use, the memory gap between chrome and FF shrinks a lot.
> > Mike
> > On Sun, Jun 21, 2009 at 10:46 AM, Dan Kegel <d...@kegel.com> wrote:
> >> On Sun, Jun 21, 2009 at 10:22 AM, Mike Belshe<mbel...@google.com> wrote:
> >> > First off - kudos to the author for posting the source and steps to
> >> > reproduce! Most don't do that!
> >> > Second, the author is basically right. Since he's running on Vista, its
> >> a
> >> > bit hard to tell whether his stats included shared memory or not; using
> >> the
> >> > default memory statistic ("Memory (Private Working Set)") is actually a
> >> > pretty good measure to just sum. But he doesn't say which measurement
> >> he
> >> > used.
> >> Wait, why doesn't his program itself do the summing?
> >> (I don't see it in there.)
> >> Wouldn't that get rid of the ambiguity?
> >> How hard would it be to add that and repost?
> >> - Dan
> Second, the author is basically right. Since he's running on Vista, > its a bit hard to tell whether his stats included shared memory or > not; using the default memory statistic ("Memory (Private Working > Set)") is actually a pretty good measure to just sum. But he > doesn't say which measurement he used.
Doesn't Private Bytes accurately represent the private memory for a given process? I thought the whole point of that was that it didn't measure any shared memory pools.
On Mon, Jun 22, 2009 at 9:29 AM, Mike Beltzner <beltz...@mozilla.com> wrote: > On 21-Jun-09, at 10:22 AM, Mike Belshe wrote:
> Second, the author is basically right. Since he's running on Vista, its a >> bit hard to tell whether his stats included shared memory or not; using the >> default memory statistic ("Memory (Private Working Set)") is actually a >> pretty good measure to just sum. But he doesn't say which measurement he >> used.
> Doesn't Private Bytes accurately represent the private memory for a given > process? I thought the whole point of that was that it didn't measure any > shared memory pools.
Yes, that accurately represents the private memory for a process, but it doesn't reflect the user's experience. Windows generally tracks working set. Why? Because the working set is the amount of memory *not available to other apps*. If other apps can have the memory, then using the bytes is inconsequential.
For most applications, there isn't much difference between private bytes and working set private bytes. However, because of Chrome's multi-proc architecture, there is a big difference. The reason is because Chrome intentionally gives memory back to the OS. For instance, on my current instance of Chrome, I'm using 16 tabs. The sum of the private bytes is 514408. The sum of the private working set bytes is 275040, nearly half of the private bytes number. This is on a machine with 8GB of RAM, so there is plenty of memory to go around. But if some other app wants the memory, Chrome gave it back to the OS and will suffer the page faults to get it back. Since Chrome has given it back to the OS (and has volunteered to take the performance consequences of getting it back), I don't think it should be counted as Chrome usage. Others may disagree. But Windows uses working set as the primary metric for all applications the OS folks agree that working set is the right way to account for memory usage.
Single process browsers have a hard time giving memory back, because they can't differentiate which pages are accounted to unused, background tabs and which pages are accounted to the active, in-use tabs.
Finally, the common metric which definitely doesn't work well is Windows XP's default metric: working set (private + shared). Because of shared memory between processes, simply summing the working set will far overstate the actual RAM used. Part of the motivation with Vista changing the default metric from working set to private working set was precisely to deal with the issue of better accounting of shared memory.
This explanation actually shows me the source of this serious jank (I hope I
am using the term in the right context) I am having all of the time.I am
getting back to Chrome after a few minutes of dealing with some other
application and I have to wait, sometimes even for twenty seconds or more,
until I get the control back on the tab contents.
Sometimes I am not using a tab for a few minutes (or more) and when I switch
back to it, it takes it twenty seconds or more until I get the control back
of the tab contents.
:(
On Mon, Jun 22, 2009 at 19:57, Mike Belshe <mbel...@google.com> wrote:
> On Mon, Jun 22, 2009 at 9:29 AM, Mike Beltzner <beltz...@mozilla.com>wrote:
>> On 21-Jun-09, at 10:22 AM, Mike Belshe wrote:
>> Second, the author is basically right. Since he's running on Vista, its
>>> a bit hard to tell whether his stats included shared memory or not; using
>>> the default memory statistic ("Memory (Private Working Set)") is actually a
>>> pretty good measure to just sum. But he doesn't say which measurement he
>>> used.
>> Doesn't Private Bytes accurately represent the private memory for a given
>> process? I thought the whole point of that was that it didn't measure any
>> shared memory pools.
> Yes, that accurately represents the private memory for a process, but it
> doesn't reflect the user's experience. Windows generally tracks working
> set. Why? Because the working set is the amount of memory *not available
> to other apps*. If other apps can have the memory, then using the bytes is
> inconsequential.
> For most applications, there isn't much difference between private bytes
> and working set private bytes. However, because of Chrome's multi-proc
> architecture, there is a big difference. The reason is because
> Chrome intentionally gives memory back to the OS. For instance, on my
> current instance of Chrome, I'm using 16 tabs. The sum of the private bytes
> is 514408. The sum of the private working set bytes is 275040, nearly half
> of the private bytes number. This is on a machine with 8GB of RAM, so there
> is plenty of memory to go around. But if some other app wants the memory,
> Chrome gave it back to the OS and will suffer the page faults to get it
> back. Since Chrome has given it back to the OS (and has volunteered to take
> the performance consequences of getting it back), I don't think it should be
> counted as Chrome usage. Others may disagree. But Windows uses working set
> as the primary metric for all applications the OS folks agree that working
> set is the right way to account for memory usage.
> Single process browsers have a hard time giving memory back, because they
> can't differentiate which pages are accounted to unused, background tabs and
> which pages are accounted to the active, in-use tabs.
> Finally, the common metric which definitely doesn't work well is Windows
> XP's default metric: working set (private + shared). Because of shared
> memory between processes, simply summing the working set will far overstate
> the actual RAM used. Part of the motivation with Vista changing the default
> metric from working set to private working set was precisely to deal with
> the issue of better accounting of shared memory.
> This explanation actually shows me the source of this serious jank (I hope I
> am using the term in the right context) I am having all of the time.
> I am getting back to Chrome after a few minutes of dealing with some other
> application and I have to wait, sometimes even for twenty seconds or more,
> until I get the control back on the tab contents.
> Sometimes I am not using a tab for a few minutes (or more) and when I switch
> back to it, it takes it twenty seconds or more until I get the control back
> of the tab contents.
> :(
> ☆PhistucK
> On Mon, Jun 22, 2009 at 19:57, Mike Belshe <mbel...@google.com> wrote:
>> On Mon, Jun 22, 2009 at 9:29 AM, Mike Beltzner <beltz...@mozilla.com>
>> wrote:
>>> On 21-Jun-09, at 10:22 AM, Mike Belshe wrote:
>>>> Second, the author is basically right. Since he's running on Vista, its
>>>> a bit hard to tell whether his stats included shared memory or not; using
>>>> the default memory statistic ("Memory (Private Working Set)") is actually a
>>>> pretty good measure to just sum. But he doesn't say which measurement he
>>>> used.
>>> Doesn't Private Bytes accurately represent the private memory for a given
>>> process? I thought the whole point of that was that it didn't measure any
>>> shared memory pools.
>> Yes, that accurately represents the private memory for a process, but it
>> doesn't reflect the user's experience. Windows generally tracks working
>> set. Why? Because the working set is the amount of memory *not available
>> to other apps*. If other apps can have the memory, then using the bytes is
>> inconsequential.
>> For most applications, there isn't much difference between private bytes
>> and working set private bytes. However, because of Chrome's multi-proc
>> architecture, there is a big difference. The reason is because
>> Chrome intentionally gives memory back to the OS. For instance, on my
>> current instance of Chrome, I'm using 16 tabs. The sum of the private bytes
>> is 514408. The sum of the private working set bytes is 275040, nearly half
>> of the private bytes number. This is on a machine with 8GB of RAM, so there
>> is plenty of memory to go around. But if some other app wants the memory,
>> Chrome gave it back to the OS and will suffer the page faults to get it
>> back. Since Chrome has given it back to the OS (and has volunteered to take
>> the performance consequences of getting it back), I don't think it should be
>> counted as Chrome usage. Others may disagree. But Windows uses working set
>> as the primary metric for all applications the OS folks agree that working
>> set is the right way to account for memory usage.
>> Single process browsers have a hard time giving memory back, because they
>> can't differentiate which pages are accounted to unused, background tabs and
>> which pages are accounted to the active, in-use tabs.
>> Finally, the common metric which definitely doesn't work well is Windows
>> XP's default metric: working set (private + shared). Because of shared
>> memory between processes, simply summing the working set will far overstate
>> the actual RAM used. Part of the motivation with Vista changing the default
>> metric from working set to private working set was precisely to deal with
>> the issue of better accounting of shared memory.
>> Mike
> Have you tried running with --memory-model=high ?
> 2009/6/23 PhistucK <phist...@gmail.com>:
> > This explanation actually shows me the source of this serious jank (I
> hope I
> > am using the term in the right context) I am having all of the time.
> > I am getting back to Chrome after a few minutes of dealing with some
> other
> > application and I have to wait, sometimes even for twenty seconds or
> more,
> > until I get the control back on the tab contents.
> > Sometimes I am not using a tab for a few minutes (or more) and when I
> switch
> > back to it, it takes it twenty seconds or more until I get the control
> back
> > of the tab contents.
> > :(
> > ☆PhistucK
> > On Mon, Jun 22, 2009 at 19:57, Mike Belshe <mbel...@google.com> wrote:
> >> On Mon, Jun 22, 2009 at 9:29 AM, Mike Beltzner <beltz...@mozilla.com>
> >> wrote:
> >>> On 21-Jun-09, at 10:22 AM, Mike Belshe wrote:
> >>>> Second, the author is basically right. Since he's running on Vista,
> its
> >>>> a bit hard to tell whether his stats included shared memory or not;
> using
> >>>> the default memory statistic ("Memory (Private Working Set)") is
> actually a
> >>>> pretty good measure to just sum. But he doesn't say which measurement
> he
> >>>> used.
> >>> Doesn't Private Bytes accurately represent the private memory for a
> given
> >>> process? I thought the whole point of that was that it didn't measure
> any
> >>> shared memory pools.
> >> Yes, that accurately represents the private memory for a process, but it
> >> doesn't reflect the user's experience. Windows generally tracks working
> >> set. Why? Because the working set is the amount of memory *not
> available
> >> to other apps*. If other apps can have the memory, then using the bytes
> is
> >> inconsequential.
> >> For most applications, there isn't much difference between private bytes
> >> and working set private bytes. However, because of Chrome's multi-proc
> >> architecture, there is a big difference. The reason is because
> >> Chrome intentionally gives memory back to the OS. For instance, on my
> >> current instance of Chrome, I'm using 16 tabs. The sum of the private
> bytes
> >> is 514408. The sum of the private working set bytes is 275040, nearly
> half
> >> of the private bytes number. This is on a machine with 8GB of RAM, so
> there
> >> is plenty of memory to go around. But if some other app wants the
> memory,
> >> Chrome gave it back to the OS and will suffer the page faults to get it
> >> back. Since Chrome has given it back to the OS (and has volunteered to
> take
> >> the performance consequences of getting it back), I don't think it
> should be
> >> counted as Chrome usage. Others may disagree. But Windows uses working
> set
> >> as the primary metric for all applications the OS folks agree that
> working
> >> set is the right way to account for memory usage.
> >> Single process browsers have a hard time giving memory back, because
> they
> >> can't differentiate which pages are accounted to unused, background tabs
> and
> >> which pages are accounted to the active, in-use tabs.
> >> Finally, the common metric which definitely doesn't work well is Windows
> >> XP's default metric: working set (private + shared). Because of shared
> >> memory between processes, simply summing the working set will far
> overstate
> >> the actual RAM used. Part of the motivation with Vista changing the
> default
> >> metric from working set to private working set was precisely to deal
> with
> >> the issue of better accounting of shared memory.
> >> Mike
Mike, yes we (I) increased the number of renderer processes for
machines with lots of ram. I think it tops now to 40 processes.
Our previous limit was not based on calculation but because we had
WaitForMultipleObjects(..) which has a 64 objects maximum and we had 2
objects per process so our limit was 31 so to give us some slack we
settled on 20
Wow, that changed my whole browsing experience.I got back to the computer
after it has been on all of the night, with Chrome (and others) running and
when I got back to Chrome, I did not even have to wait for a bit!!!
Thank you very much for pointing it out. It was quite frustrating before
(but I liked everything else about Chrome, so I kept on using it).
What are the implications, though?
Not giving up the space to other applications and that is it?
> Have you tried running with --memory-model=high ?
> 2009/6/23 PhistucK <phist...@gmail.com>:
> > This explanation actually shows me the source of this serious jank (I
> hope I
> > am using the term in the right context) I am having all of the time.
> > I am getting back to Chrome after a few minutes of dealing with some
> other
> > application and I have to wait, sometimes even for twenty seconds or
> more,
> > until I get the control back on the tab contents.
> > Sometimes I am not using a tab for a few minutes (or more) and when I
> switch
> > back to it, it takes it twenty seconds or more until I get the control
> back
> > of the tab contents.
> > :(
> > ☆PhistucK
> > On Mon, Jun 22, 2009 at 19:57, Mike Belshe <mbel...@google.com> wrote:
> >> On Mon, Jun 22, 2009 at 9:29 AM, Mike Beltzner <beltz...@mozilla.com>
> >> wrote:
> >>> On 21-Jun-09, at 10:22 AM, Mike Belshe wrote:
> >>>> Second, the author is basically right. Since he's running on Vista,
> its
> >>>> a bit hard to tell whether his stats included shared memory or not;
> using
> >>>> the default memory statistic ("Memory (Private Working Set)") is
> actually a
> >>>> pretty good measure to just sum. But he doesn't say which measurement
> he
> >>>> used.
> >>> Doesn't Private Bytes accurately represent the private memory for a
> given
> >>> process? I thought the whole point of that was that it didn't measure
> any
> >>> shared memory pools.
> >> Yes, that accurately represents the private memory for a process, but it
> >> doesn't reflect the user's experience. Windows generally tracks working
> >> set. Why? Because the working set is the amount of memory *not
> available
> >> to other apps*. If other apps can have the memory, then using the bytes
> is
> >> inconsequential.
> >> For most applications, there isn't much difference between private bytes
> >> and working set private bytes. However, because of Chrome's multi-proc
> >> architecture, there is a big difference. The reason is because
> >> Chrome intentionally gives memory back to the OS. For instance, on my
> >> current instance of Chrome, I'm using 16 tabs. The sum of the private
> bytes
> >> is 514408. The sum of the private working set bytes is 275040, nearly
> half
> >> of the private bytes number. This is on a machine with 8GB of RAM, so
> there
> >> is plenty of memory to go around. But if some other app wants the
> memory,
> >> Chrome gave it back to the OS and will suffer the page faults to get it
> >> back. Since Chrome has given it back to the OS (and has volunteered to
> take
> >> the performance consequences of getting it back), I don't think it
> should be
> >> counted as Chrome usage. Others may disagree. But Windows uses working
> set
> >> as the primary metric for all applications the OS folks agree that
> working
> >> set is the right way to account for memory usage.
> >> Single process browsers have a hard time giving memory back, because
> they
> >> can't differentiate which pages are accounted to unused, background tabs
> and
> >> which pages are accounted to the active, in-use tabs.
> >> Finally, the common metric which definitely doesn't work well is Windows
> >> XP's default metric: working set (private + shared). Because of shared
> >> memory between processes, simply summing the working set will far
> overstate
> >> the actual RAM used. Part of the motivation with Vista changing the
> default
> >> metric from working set to private working set was precisely to deal
> with
> >> the issue of better accounting of shared memory.
> >> Mike
FWIW, I strongly believe we should move the default to --memory-model=high. This is what pretty much every other app in the world does, and we mostly penalize ourselves when the OS aggressively swaps us out for a dumb reason (which yes, Windows does do). We have a lot of complaints of "I came back the next hour/day/whatever and everything was unresponsive". I don't think our current tradeoff is the right one.
I know Mike wants to be a good citizen and feels like if the OS swapped you out it really needed that RAM, but in my own observations of my machine the OS swaps for retarded reasons and I gain nothing but headaches.
Anecdotally, a couple of people have said "it works" and a couple of people have said "it makes no difference". I do believe that people doing compiles could see a difference.
To determine if it was real, we did an experiment with memory model high and memory model medium and measured the whiteout duration. We did not see any statistical difference between the two. It could be that that was not a good test, but we don't know of a better test.
If we have a better test, let's do an A/B test and find out the answer to this puzzling question. We also know that memory model high on real world users uses about 25% more RAM.
Another option is to be less aggressive on the memory model medium.
Mike
On Tue, Jun 23, 2009 at 11:34 PM, Peter Kasting <pkast...@chromium.org>wrote:
> FWIW, I strongly believe we should move the default to --memory-model=high. > This is what pretty much every other app in the world does, and we mostly > penalize ourselves when the OS aggressively swaps us out for a dumb reason > (which yes, Windows does do). > We have a lot of complaints of "I came back the next hour/day/whatever and > everything was unresponsive". I don't think our current tradeoff is the > right one.
> I know Mike wants to be a good citizen and feels like if the OS swapped you > out it really needed that RAM, but in my own observations of my machine the > OS swaps for retarded reasons and I gain nothing but headaches.
+1. Most people are not doing compiles, we're trying to say that people live
in the web and in their browser, and that their browser is the primary
application. For me at least, that is true. The browser is the app I use the
most -- the only other app I use regularly is an ssh client, which can
usually fit in memory or get swapped back in much quicker than Chrome.
> FWIW, I strongly believe we should move the default to --memory-model=high.
> This is what pretty much every other app in the world does, and we mostly
> penalize ourselves when the OS aggressively swaps us out for a dumb reason
> (which yes, Windows does do).
> We have a lot of complaints of "I came back the next hour/day/whatever and
> everything was unresponsive". I don't think our current tradeoff is the
> right one.
> I know Mike wants to be a good citizen and feels like if the OS swapped you
> out it really needed that RAM, but in my own observations of my machine the
> OS swaps for retarded reasons and I gain nothing but headaches.
On Wed, Jun 24, 2009 at 9:39 AM, Ian Fette<i...@chromium.org> wrote:
> +1. Most people are not doing compiles, we're trying to say that people live
> in the web and in their browser, and that their browser is the primary
> application. For me at least, that is true. The browser is the app I use the
> most -- the only other app I use regularly is an ssh client, which can
> usually fit in memory or get swapped back in much quicker than Chrome.
>> FWIW, I strongly believe we should move the default to
>> --memory-model=high. This is what pretty much every other app in the world
>> does, and we mostly penalize ourselves when the OS aggressively swaps us out
>> for a dumb reason (which yes, Windows does do).
>> We have a lot of complaints of "I came back the next hour/day/whatever and
>> everything was unresponsive". I don't think our current tradeoff is the
>> right one.
>> I know Mike wants to be a good citizen and feels like if the OS swapped
>> you out it really needed that RAM, but in my own observations of my machine
>> the OS swaps for retarded reasons and I gain nothing but headaches.
>> PK
On Wed, Jun 24, 2009 at 9:39 AM, Ian Fette <i...@chromium.org> wrote:
> +1. Most people are not doing compiles, we're trying to say that people
> live in the web and in their browser, and that their browser is the primary
> application. For me at least, that is true. The browser is the app I use the
> most -- the only other app I use regularly is an ssh client, which can
> usually fit in memory or get swapped back in much quicker than Chrome.
This doesn't make sense as a use case, because if there is nothing else
eating your memory, then the memory doesn't have to "swap in". It's already
there! :-) For users with plenty of RAM like you, memory-model=medium
should work just fine.
The only people that might be effected by this is people that do have
something else competing for the memory (like a compile, or they are on a
low-memory box and outlook is eating it).
I do worry that virus scanners could churn through memory causing similar
effects, but again, we measured for this and so far have been unable to
detect any difference.
At this point we could change to memory-model=high, despite having no
real-world data that this is a problem. Chrome would be perceived to use
25% more memory, and the folks on this thread that have compiles going might
feel a better experience. If we don't care about a 25% jump in memory use
then we should switch the default even though data suggests it won't help.
One more possibility: maybe there is a bug we haven't yet identified.
>> FWIW, I strongly believe we should move the default to
>> --memory-model=high. This is what pretty much every other app in the world
>> does, and we mostly penalize ourselves when the OS aggressively swaps us out
>> for a dumb reason (which yes, Windows does do).
>> We have a lot of complaints of "I came back the next hour/day/whatever and
>> everything was unresponsive". I don't think our current tradeoff is the
>> right one.
>> I know Mike wants to be a good citizen and feels like if the OS swapped
>> you out it really needed that RAM, but in my own observations of my machine
>> the OS swaps for retarded reasons and I gain nothing but headaches.
I am willing to volunteer to be a test case if you need one, tell me what to
do so you will be able to monitor.Before I added that switch, it was pretty
horrible.
Though I am building stuff with Java, XSLT, JavaScript that process a lot of
files (HTMLs) and viewing and refreshing a lot of pages (in Chrome, mostly,
but sometimes in other browsers for cross browser support), plus Eclipse and
Outlook, if it matters.
On Wed, Jun 24, 2009 at 19:46, Mike Belshe <mbel...@google.com> wrote:
> On Wed, Jun 24, 2009 at 9:39 AM, Ian Fette <i...@chromium.org> wrote:
>> +1. Most people are not doing compiles, we're trying to say that people
>> live in the web and in their browser, and that their browser is the primary
>> application. For me at least, that is true. The browser is the app I use the
>> most -- the only other app I use regularly is an ssh client, which can
>> usually fit in memory or get swapped back in much quicker than Chrome.
> This doesn't make sense as a use case, because if there is nothing else
> eating your memory, then the memory doesn't have to "swap in". It's already
> there! :-) For users with plenty of RAM like you, memory-model=medium
> should work just fine.
> The only people that might be effected by this is people that do have
> something else competing for the memory (like a compile, or they are on a
> low-memory box and outlook is eating it).
> I do worry that virus scanners could churn through memory causing similar
> effects, but again, we measured for this and so far have been unable to
> detect any difference.
> At this point we could change to memory-model=high, despite having no
> real-world data that this is a problem. Chrome would be perceived to use
> 25% more memory, and the folks on this thread that have compiles going might
> feel a better experience. If we don't care about a 25% jump in memory use
> then we should switch the default even though data suggests it won't help.
> One more possibility: maybe there is a bug we haven't yet identified.
> Mike
>> 2009/6/23 Peter Kasting <pkast...@chromium.org>
>>> FWIW, I strongly believe we should move the default to
>>> --memory-model=high. This is what pretty much every other app in the world
>>> does, and we mostly penalize ourselves when the OS aggressively swaps us out
>>> for a dumb reason (which yes, Windows does do).
>>> We have a lot of complaints of "I came back the next hour/day/whatever
>>> and everything was unresponsive". I don't think our current tradeoff is the
>>> right one.
>>> I know Mike wants to be a good citizen and feels like if the OS swapped
>>> you out it really needed that RAM, but in my own observations of my machine
>>> the OS swaps for retarded reasons and I gain nothing but headaches.
