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? ☆PhistucK 2009/6/23 Dean McNamee <de...@chromium.org> > 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 > >> > >> > >> > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---