| Summary: | mozilla-firefox large memory footprint, while mozilla-firefox-bin is much smaller | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | devsk <funtoos> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
devsk
2008-08-27 16:31:43 UTC
when I said "memory", I meant RES column of 'top' output. The numbers I quoted are after "settling period of about 30 seconds" because firefox has this new feature of cleaning its used memory periodically. Mozilla profiles the code, uses distinct compiler flags for certain pats of the code and knows exactly, which code better not to optimize. Also, building is only one part, but moreso your configuration - caching more website data requires more memory. Another issue may be improper calculation of the used memory, as the data of free, top, ps, etc. do not reflect the real memory usage. Most likely what you're noticing is a non-issue. Nothing we can do. (In reply to comment #2) > Mozilla profiles the code, uses distinct compiler flags for certain pats of the > code and knows exactly, which code better not to optimize. Also, building is > only one part, but moreso your configuration - caching more website data > requires more memory. Another issue may be improper calculation of the used > memory, as the data of free, top, ps, etc. do not reflect the real memory > usage. > > Most likely what you're noticing is a non-issue. > I am sorry. How is it a non-issue? I said its the same number of tabs, same set of tabs (restored using "open my windows from last time" option) in a steady state observed over a period of time (many days) using a tool which reflects resident memory of the process. I think its not about code optimization. I think most likely its about specific config selection as opposed to the default selection. I know about caching and how to interpret values reported by free. So, please don't brush it over as non-issue. I have to restart firefox often because of this because I have some 30 tabs open all the time. It is a real issue with the way gentoo is setting up the build config. And as the rendering test indicated, its something to do with our default toolkit selection and/or rendering engine. If we can figure that that is the case, we can pursue that further. But someone has to help understand this problem better. BTW, I have observed this behavior on multiple x86 boxes. (In reply to comment #3) > Nothing we can do. > Yes, we can. If we find that cairo is the culprit, we can just use the default renderer as a workaround. We don't even know where the problem is coming from at this time. How can we say we can't do anything? Please work with me here. Its a genuine problem. I wouldn't file a bug just like that. Many people might be seeing it but brushing it over as "ohh, firefox is a hog!" (In reply to comment #4) > Yes, we can. If we find that cairo is the culprit, we can just use the default > renderer as a workaround. We don't even know where the problem is coming from > at this time. How can we say we can't do anything? Please work with me here. > Its a genuine problem. I wouldn't file a bug just like that. Many people might > be seeing it but brushing it over as "ohh, firefox is a hog!" > Well, feel free to work on it... I did find that if I hack the ebuild to run configure with options from the about:buildconfig of the mozilla-firefox-bin version, its not leaky anymore but the configure options list is too large to conclude which of those is responsible for memory consumption by exclusion: it takes a long time to build mozilla-firefox. So, I give up and learn to like the -bin version....:-) |
