If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Opening the same satic file in multiple tabs for cross reference, firefox easily grabs more a GB of memory.

RESOLVED INCOMPLETE

Status

()

Firefox
Untriaged
--
major
RESOLVED INCOMPLETE
2 years ago
a year ago

People

(Reporter: கூர்த்தலறி, Unassigned)

Tracking

({testcase-wanted})

45 Branch
x86_64
Windows 7
testcase-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8734309 [details]
memory-report.json.gz

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Steps to reproduce:

I walk-through a large code base indexed by OpenGrok. Few files are huge. For instance, a file I work on everyday is of size 2.7MB(yes this is a very old and very large project)

If I open the same file in multiple tabs for cross reference, firefox easily grabs more a GB of memory.

I use firefox 45.0.1 over Windows 7. Please find the attachment for about:memory Measurements.


Actual results:

For the same static files, the separate DOMs were created leading huge memory occupation. For the above mentioned 2.7MB file, on a single tab it occupies, 250+ MB, so if I open in four/five tabs, voila!, 1.5GB is reserved.


Expected results:

Would it be possible to use same DOM across multiple tabs, if the files are same. 

if there is a manual provision to mention or group tabs by hand, which can use same DOM tree, that would help me a lot. 

may be with some sort of url matching, tabs with similar DOM trees can be made to use lesser memory, not just for static files.
(Reporter)

Updated

2 years ago
Severity: normal → major
(Reporter)

Updated

2 years ago
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64

Comment 1

2 years ago
Hi,

Can you please attach or paste a link where can I find similar files like yours to test them? 
Thank you.
Component: Untriaged → General
Flags: needinfo?(selva.developer)

Updated

2 years ago
Keywords: testcase-wanted

Comment 2

2 years ago
--> untriaged until we know what's causing the memory usage. :njn, maybe you can help with that based on the attached memory-report ?
Component: General → Untriaged
Flags: needinfo?(n.nethercote)
> For the same static files, the separate DOMs were created leading huge
> memory occupation. For the above mentioned 2.7MB file, on a single tab it
> occupies, 250+ MB, so if I open in four/five tabs, voila!, 1.5GB is reserved.

The attached memory reports show something close to what's described:

> 826.94 MB (100.0%) -- explicit
> ├──582.64 MB (70.46%) -- window-objects
> │  ├──188.06 MB (22.74%) ++ top(<anonymized-1000>, id=1000)
> │  ├───90.40 MB (10.93%) ++ top(<anonymized-1037>, id=1037)
> │  ├───79.93 MB (09.67%) ++ top(<anonymized-1029>, id=1029)
> │  ├───79.12 MB (09.57%) ++ top(<anonymized-1048>, id=1048)
> │  ├───78.89 MB (09.54%) ++ top(<anonymized-1043>, id=1043)
> │  ├───25.91 MB (03.13%) ++ top(<anonymized-1025>, id=1025)

The numbers are in the 78--188 MiB range rather than 250.

Looking at two of the tabs:

> │  ├───90.40 MB (10.93%) -- top(<anonymized-1037>, id=1037)
> │  │   ├──90.25 MB (10.91%) -- active
> │  │   │  ├──90.25 MB (10.91%) -- window(<anonymized-1047>)
> │  │   │  │  ├──50.00 MB (06.05%) -- dom
> │  │   │  │  │  ├──36.67 MB (04.43%) ── element-nodes
> │  │   │  │  │  ├──12.33 MB (01.49%) ── text-nodes
> │  │   │  │  │  └───1.01 MB (00.12%) ++ (3 tiny)
> │  │   │  │  ├──39.83 MB (04.82%) -- layout
> │  │   │  │  │  ├──21.39 MB (02.59%) -- frames
> │  │   │  │  │  │  ├──13.77 MB (01.67%) ── nsTextFrame
> │  │   │  │  │  │  └───7.61 MB (00.92%) ++ (3 tiny)
> │  │   │  │  │  ├──12.43 MB (01.50%) ── text-runs
> │  │   │  │  │  └───6.01 MB (00.73%) ++ (7 tiny)
> │  │   │  │  └───0.42 MB (00.05%) ++ (3 tiny)
> │  │   │  └───0.00 MB (00.00%) ── window(<anonymized-1037>)/dom/other
> │  │   └───0.15 MB (00.02%) ++ js-zone(0x4be65000)
> │  ├───79.93 MB (09.67%) -- top(<anonymized-1029>, id=1029)
> │  │   ├──79.78 MB (09.65%) -- active
> │  │   │  ├──79.73 MB (09.64%) -- window(<anonymized-1035>)
> │  │   │  │  ├──50.00 MB (06.05%) -- dom
> │  │   │  │  │  ├──36.67 MB (04.43%) ── element-nodes
> │  │   │  │  │  ├──12.33 MB (01.49%) ── text-nodes
> │  │   │  │  │  └───1.01 MB (00.12%) ++ (3 tiny)
> │  │   │  │  ├──29.31 MB (03.54%) -- layout
> │  │   │  │  │  ├──21.39 MB (02.59%) -- frames
> │  │   │  │  │  │  ├──13.77 MB (01.67%) ── nsTextFrame
> │  │   │  │  │  │  └───7.61 MB (00.92%) ++ (3 tiny)
> │  │   │  │  │  └───7.92 MB (00.96%) ++ (8 tiny)
> │  │   │  │  └───0.42 MB (00.05%) ++ (3 tiny)
> │  │   │  └───0.05 MB (00.01%) ++ (2 tiny)
> │  │   └───0.15 MB (00.02%) ++ js-zone(0xc455800)

The DOM measurements are identical and the layout measurements are similar, although the latter has fewer text runs. Perhaps text runs are created only when a document is scrolled?

Anyway, this looks very much as I expected from the description. If we could share DOM and layout structures between tabs that would clearly help in this case. However, in general these data structures can be changed after loading and so you'd have to have a way to determine that a webpage is static before it can be shared, and I suspect that would be very difficult.
Flags: needinfo?(n.nethercote)
Hi,
Marking this as Resolved: Incomplete due to the lack of response from the reporter.
Reporter, please feel free to reopen it if you are still having this issue on the latest Firefox version.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(selva.developer)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.