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
-~----------~----~----~----~------~----~------~--~---
