32-bit Firefox on Win7 uses 30MB more memory than 64-bit Firefox on Win10
Categories
(Testing :: AWSY, defect, P3)
Tracking
(Not tracked)
People
(Reporter: erahm, Assigned: jfkthame)
References
(Blocks 1 open bug)
Details
(Whiteboard: [overhead:30MB])
Comment 1•6 years ago
|
||
Reporter | ||
Comment 2•6 years ago
|
||
Reporter | ||
Comment 3•6 years ago
|
||
Comment 4•6 years ago
|
||
Comment 5•6 years ago
|
||
Reporter | ||
Comment 6•6 years ago
|
||
Reporter | ||
Comment 8•6 years ago
|
||
Reporter | ||
Comment 9•6 years ago
|
||
Reporter | ||
Comment 10•6 years ago
|
||
Reporter | ||
Comment 11•6 years ago
|
||
Telemetry has confirmed that this is limited to 32-bit builds. It's most prevalent on Windows 7/8, but there is a small cohort on Windows 10 as well. Both the number of Win7 users (37%) and 32-bit browser users (26%) continue to fall. On beta 67 we're seeing roughly 3.5% of 32-bit samples showing this bump. Combined it looks something like 2% of Windows samples. Telemetry for total memory usage doesn't show a correlating spike which seems to imply we don't see this behavior in all content processes.
Interestingly, at least in our test infrastructure, initial results from the font sharing work in bug 1514869 ended up clearing the large bump. It's possible that by being the first 32-bit program to access font data we take some sort of large hit loading up various windows dependencies, but it's not clear exactly what is going on.
Updated•5 years ago
|
Comment 12•5 years ago
|
||
(In reply to Eric Rahm [:erahm] from comment #11)
Telemetry has confirmed that this is limited to 32-bit builds. It's most prevalent on Windows 7/8, but there is a small cohort on Windows 10 as well. Both the number of Win7 users (37%) and 32-bit browser users (26%) continue to fall. On beta 67 we're seeing roughly 3.5% of 32-bit samples showing this bump. Combined it looks something like 2% of Windows samples. Telemetry for total memory usage doesn't show a correlating spike which seems to imply we don't see this behavior in all content processes.
Interestingly, at least in our test infrastructure, initial results from the font sharing work in bug 1514869 ended up clearing the large bump. It's possible that by being the first 32-bit program to access font data we take some sort of large hit loading up various windows dependencies, but it's not clear exactly what is going on.
I am sorry but I am seeing this bug in Win 7 64-bit also for a very long time now.
Comment 13•4 years ago
|
||
I think this got fixed by bug 1533462, as that saw a 30MB improvement on 32-bit Windows:
71% Base Content Resident Unique Memory windows7-32-shippable opt 41,179,818.67 -> 11,981,141.33
Description
•