Updates:
Status: Assigned
Owner: [email protected]
Labels: -Area-Misc Area-WebKit Performance
Comment #2 on issue 1940 by [email protected]: Heavy memory consumption with
large files
http://code.google.com/p/chromium/issues/detail?id=1940
Sorry it took so long to get back to you. Launching a new browser tends to
generate a lot of work and a pile
of issue reports.
Given that so much time has passed I looked into this with FireFox 3 and
Chromium 2.0.157.0 (Developer Build
7655) which you can download at
http://build.chromium.org/buildbot/continuous/LATEST/
There are a couple of things you should know.
1. Much of the performance issue you saw may have been due more to our
use of WinHTTP as the network stack
for the initial releases. The latest builds are using our own network
stack.
2. You can get a nice report on the memory usage of Chromium by using
about:memory
3. While Inspector is a great tool we get as part of WebKit, it is not
very tight or efficient. I am
amazed that it even ran with that huge file! Everyone wants Inspector to
be better but it just isn't at the
top of the list yet -- and for most things it is good enough.
My machine is a fairly wimpy laptop with 2G of RAM. I was running a bunch
of applications at the same time,
including Visual Studio 2005 and iTunes. There wasn't much RAM left. :)
Anyway, I loaded up the great big PHP Manual from local disk into both
Chromium and FireFox. For me the memory
usage was about the same, about 450M in each browser. Chromium happened to
finish loading faster but I can't
say that is repeatable given all the other stuff I was doing at the same
time.
I would be interested in hearing how things go for you on the latest
version of Chromium. Be sure to run each
browser all by itself (heck throw in IE and Opera!), and give the OS a
chance to recover a bit. After my
little test the Resource Monitor in Vista took a good long time to page
everything else back in.
In your blog you say that we have a memory leak. That's probably not the
right term. If it were a memory leak
then closing the tab wouldn't free up the RAM, right? After closing the
tab everything settled back down to
where it was.
If you look at the builds with "purify" at
http://build.chromium.org/buildbot/waterfall/waterfall you can see
the memory tests we run continuously. As you know, memory leaks and other
memory allocation mistakes can be a
bugger to find so we use this tool (and others) all the time. You can see
the allocation bugs we are currently
working on by searching this bug database for purify. I believe there are
about 20. However, none of these
are likely to reduce the amount of memory required to store the DOM and all
the objects associated with that
16M HTML file.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
