4 ms·
Nope - the huge memory usage for Chrome is because this analysis is complete rubbish - it's double counting all the shared memory for each process, as you sugge
by dflock 17y ago
Nope - the huge memory usage for Chrome is because this analysis is complete rubbish - it's double counting all the shared memory for each process, as you suggested.
- barrkel 17y agoHe is using Process.PrivateMemorySize64 in .NET. It doesn't double-count, because it only counts non-shared pages. Non-shared working set pages are probably the most relevant measure, as a process-per-tab model will have lots of address space and may use memory mapping extensively, and so have lots of non-shared pages, but not actually touch many of those pages, and end up with a relatively small working set. However, .NET's Process class doesn't have an equivalent property to Process Explorer's "WS Private" column. EDIT: Sure enough, a quick eyeball of some Chrome subprocesses using Process Explorer gives me these results: Private WS Private 1416 460 14916 7952 12084 9780 16780 13972 16164 11336 14812 12040 10284 4444 19140 15400 All numbers in KB. Non-shared working set impact on an unloaded machine, probably the most important measure for Windows, is usually quite a bit less than the private bytes.
- barrkel 17y agoHe talks about his utility on this page: http://dotnetperls.com/browser-memory http://dotnetperls.com/browser-memory "It uses the PrivateMemorySize64 long value from the Process collection in .NET." You can get his memory watcher from this page: http://code.google.com/p/dotnetperls-controls/downloads/list http://code.google.com/p/dotnetperls-controls/downloads/list The relevant lines from the "MemoryClass" class: long size = singleProcess.PrivateMemorySize64; double megabytes = ConvertBytesToMegabytes(size);