4 ms·

One thing that FF3.x has had on chrome is total memory footprint. About a month ago, when I was testing FF4, I noticed that the memory usage for FF4 and Chrome

One thing that FF3.x has had on chrome is total memory footprint. About a month ago, when I was testing FF4, I noticed that the memory usage for FF4 and Chrome were pretty close. I personally think Chrome consumes a bit too much memory for my liking, and I was disappointed to see FF4 following suit. Has anyone noticed if the new RC is more conservative with its memory consumption?

mbrubeck 16y ago
Part of the memory increase was caused by the new JIT. There has indeed been work done recently to bring memory back down. You can see a list of fixed and still-open bugs here: https://bugzilla.mozilla.org/showdependencytree.cgi?id=598466 https://bugzilla.mozilla.org/showdependencytree.cgi?id=59846... For example, this bug significantly reduced memory usage, and was fixed less than a month ago: https://bugzilla.mozilla.org/show_bug.cgi?id=631951 https://bugzilla.mozilla.org/show_bug.cgi?id=631951 However, there are many memory vs. speed trade-offs in software, and as memory continues to get cheaper, you'll likely see all browsers choosing to use more memory in order to run faster.
scott_s 16y ago
Keep two things in mind: virtual memory usage is not the same as physical memory usage; an application consuming more memory only matters if you can notice performance degradation elsewhere in your system.
- mrinterweb 16y ago
  I usually only pay attention to real memory. I also notice when my real memory runs out or real memory, my machine immediately start hitting swap. I guess 4 gigs is just not enough anymore. This is what I use to measure what I believe to be real memory usage for Chromium: https://gist.github.com/864606 https://gist.github.com/864606
  - scott_s 16y ago
    I actually don't think that's accurate, since it naively adds up the resident set size for each Chromium thread. The problem is that there is probably a lot of shared pages among those threads - the Chromium runtime and such. I think - but I'm not sure - that the resident set size includes pages that are shared with other threads/processes.
    - mrinterweb 16y ago
      You may be right. I get the same memory usage numbers with my Chromium memory usage script as Chromium's "Stats for nerds", but Chromium's detailed memory usage tool does link to a bug where it over reports its own memory usage. http://code.google.com/p/chromium/issues/detail?id=25454 http://code.google.com/p/chromium/issues/detail?id=25454 I guess if even Google can not figuring out how much memory Chromium is using, laymen, such as myself, are not going to do much better.
      - scott_s 16y ago
        At the very least, we can provide bounds. What you and Chromium report is an upperbound. We could provide a lowerbound defined as: def thread_low(t): return resident_set(t) - shared_set(t) lowerbound = sum(map(thread_low, all_threads)) + min(map(shared_set, all_threads)) (Forgive the Python notation, it would actually be easier to express this using actual summations if I could draw freehand, but given that I can't, I figure code would be clearer.) For all threads in the process, we know that it must be solely responsible for its resident set minus its shared set. This already is a lower bound, but it ignores what is shared. We can increase (improve) this lowerbound a bit by figuring out what the smallest shared set among all of the threads is. If my thinking is correct, then we can be sure the total memory used won't be lower than this.

mbrubeck 16y ago

Part of the memory increase was caused by the new JIT. There has indeed been work done recently to bring memory back down. You can see a list of fixed and still-open bugs here: https://bugzilla.mozilla.org/showdependencytree.cgi?id=598466 https://bugzilla.mozilla.org/showdependencytree.cgi?id=59846... For example, this bug significantly reduced memory usage, and was fixed less than a month ago: https://bugzilla.mozilla.org/show_bug.cgi?id=631951 https://bugzilla.mozilla.org/show_bug.cgi?id=631951 However, there are many memory vs. speed trade-offs in software, and as memory continues to get cheaper, you'll likely see all browsers choosing to use more memory in order to run faster.

scott_s 16y ago

Keep two things in mind: virtual memory usage is not the same as physical memory usage; an application consuming more memory only matters if you can notice performance degradation elsewhere in your system.

mrinterweb 16y ago
I usually only pay attention to real memory. I also notice when my real memory runs out or real memory, my machine immediately start hitting swap. I guess 4 gigs is just not enough anymore. This is what I use to measure what I believe to be real memory usage for Chromium: https://gist.github.com/864606 https://gist.github.com/864606
- scott_s 16y ago
  I actually don't think that's accurate, since it naively adds up the resident set size for each Chromium thread. The problem is that there is probably a lot of shared pages among those threads - the Chromium runtime and such. I think - but I'm not sure - that the resident set size includes pages that are shared with other threads/processes.
  - mrinterweb 16y ago
    You may be right. I get the same memory usage numbers with my Chromium memory usage script as Chromium's "Stats for nerds", but Chromium's detailed memory usage tool does link to a bug where it over reports its own memory usage. http://code.google.com/p/chromium/issues/detail?id=25454 http://code.google.com/p/chromium/issues/detail?id=25454 I guess if even Google can not figuring out how much memory Chromium is using, laymen, such as myself, are not going to do much better.
    - scott_s 16y ago
      At the very least, we can provide bounds. What you and Chromium report is an upperbound. We could provide a lowerbound defined as: def thread_low(t): return resident_set(t) - shared_set(t) lowerbound = sum(map(thread_low, all_threads)) + min(map(shared_set, all_threads)) (Forgive the Python notation, it would actually be easier to express this using actual summations if I could draw freehand, but given that I can't, I figure code would be clearer.) For all threads in the process, we know that it must be solely responsible for its resident set minus its shared set. This already is a lower bound, but it ignores what is shared. We can increase (improve) this lowerbound a bit by figuring out what the smallest shared set among all of the threads is. If my thinking is correct, then we can be sure the total memory used won't be lower than this.