1105634 - Interface performance suffers when many unloaded tabs exist (perf profiles included)

Status: RESOLVED WORKSFORME

(Core :: JavaScript: GC, defect)

Description

[tyaremco]

Attachment: about:support, performance and memory profiles for Test 1 and 2

Firefox's performance is worse when I have many unloaded tabs in my session.  I experience interface hangs for most operations, including tab switching. It gets progressively worse as I load tabs.  

The problem is measurable on browser start.  Below I'll show my testing method.  Performance profiles are attached.


## Testing Method ##
- open browser
- load two tabs (chosen at random; symptoms appear regardless of tab url) side-by-side at the start of the tabbar
"A" http://www.redferret.net/?p=47405
"B" http://themeforest.net/item/university-education-event-and-course-theme/full_screen_preview/8412116
- wait for any large CPU activity to stop
- begin with A focused
- start profiler
- mouseover B, wait for tooltip
- click B, keep mouse on tabbar
- mousover A, wait for tooltip
- click A
- stop profiler


## Machine ##
- Windows 7
- Thinkpad X200s
- Intel Core2 Duo CPU L9400
- 8.00GB RAM
- Mobile Intel(R) 4 Series Express Chipset Family (Driver version 8.15.10.2869)

## Profile at the time of testing ##
(about:support is included in attachment)
- less than 24hr old
- session store contains ~1000 tabs (imported from old profile)
- I have hardware acceleration disabled as I do not find any performance improvement with it enabled.  I experience the exact same symptoms.

## Machine state before profiler start ##
- 60% free RAM
- CPU 0-7%




## Test 1 ##
This test is meant to eliminate an extension as the culprit.

- start browser in Safe Mode
- execute Testing Method

Only two tabs were loaded in this test.  ~1000 tabs remained in an unloaded state.

# Results
During tab clicking and mouseover, FPS goes to near zero.  On click, the hang is noticeable.  



## Test 2 ##
This test is intended to eliminate both extensions and the excessive amounts of tabs.  I force a new session store:

- rename sessionstore.js and sessionstore-backups
- start browser in Safe Mode
- execute Testing Method

Only two tabs were loaded in this test.  No tabs remained in an unloaded state.

# Results
Performance is improved to ~14FPS on click/mouseover and hang duration is much shorter.



## Observations ##
Firefox runs considerably worse with many unloaded tabs.  Why should there be such a large performance hit in this case?



## What should happen ##
The number of unloaded tabs in the session should have no effect on interface performance when switching tabs.

Comment 1

[:Gijs (he/him)]

Benoit, can you take a look, please? From my amateur reading of the profile, this is some GC and some sync reflows - to do with ensuring the selected tab is scrolled into view - but it also seems like the total time doesn't match the time I see taken up by the individual bits of the profile (ie I see the total time listed as 7934.09ms, but the kids of that node sum up to much less than that).

Comment 2

[Benoit Girard (:BenWa)]

Looks like the problem is that they're long style flushes and periodic GC pauses. This isn't my area so I can't tell you why they happen.

Comment 3

[:Gijs (he/him)]

dholbert, I know this isn't really your specific area either - but do you have any idea what'd be up here with the style flushes, or if not, then who might be a better person to ask?

Till, same question regarding GC pauses - who would be a good person to ask?

Comment 4

[Till Schneidereit [:till]]

terrence, sfink, and jonco are our GC people. Needinfo'ing terrence as he's been looking into GC performance in the browser recently.

Comment 5

[Daniel Holbert [:dholbert]]

tyaremco, could you attach a profile generated from BenWa's "Gecko Profiler"? (An extension, different from the built-in devtools profiler. The Gecko Profiler gives much more detail about what Firefox is actually doing when it hangs, which helps to diagnose what's going on.)

Instructions here:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Thanks!

Comment 6

[tyaremco]

My thanks to everyone investigating this bug!

I'm having an issue restoring my tabs properly in nightly (bug 1112485) so this Gecko Profile is done in Firefox 36a2.

https://drive.google.com/file/d/0Bzz44z3sBxcaOVpCS3lleE1ScDA/view?usp=sharing

This time I have 1000+ tabs in one window (A) and two tabs in another (B).  The first two tabs in both windows are the same as those specified in the initial report.  The profile shows me:
- focus window A
- switch back and forth between the first two tabs in window A about ten times
- switch to window B
- wait 10 seconds
- switch back and forth between the tabs in window B about ten times

The performance difference between switching tabs in A and B is still evident using this technique.

Comment 7

[Daniel Holbert [:dholbert]]

Thanks for uploading that profile!  So, viewing it on cleopatra ( https://people.mozilla.org/~bgirard/cleopatra/ ), I see two CPU-heavy chunks at the end -- I'm guessing that's your experiment laid out in comment 6. (First window A -- lots of tabs -- and then window B -- few tabs.)

That shows the time being split between "NTWaitforMultipleObjects" (which seems to be a "wait to acquire locks" function, I think?) and JS garbage-collection code.  So, I think this is outside the scope of code I'm familiar with. Hopefully terrence can take a closer look from here.

Comment 8

[Terrence Cole [:terrence]]

The breakdown I'm seeing looks like:

  * 48% in NtWaitForMultipleObjects under XRE_Main. This is the browser being idle inbetween the noticeably laggy bits and the next interaction.
  * 16.8% in RunCycleCollectorSlice. ni? Andrew to look into this. The majority of this time is spent inside GC primitives, but that's normal. The question is what browser chrome activity is causing the CCs.
  * 16.8% in GC.
    * 8.2% in JSObject2WrappedJSMap::UpdateWeakPointersAfterGC.
    * 1.7% in processMarkStackTop.

Less than <2% of /total/ time is spent marking JS objects, which is typically the long arm with JS heavy workloads. Additionally, we're spending a ton of time in XPConnect. This would indicate some extremely heavy usage of DOM objects, but ones which have yet been converted over into the new bindings. The time in CC likely has the same root cause: lots of DOM objects.

It seems that JS GC is not the primary culprit here.

Comment 9

[Andrew McCreight [:mccr8]]

You have a thousand tabs open, so some performance problems are expected.  It is unfortunate that unloaded tabs do have some overhead.

Is the lagginess just at startup, or is it ongoing?

One thing that would be useful, if it is really GC and CC, would be to go to about:config and set javascript.options.mem.log to true, then look at the Browser Console.  If you could attach some of the GC and CC logs that seem either typical or maybe particularly bad (the max pause stat is probably what you are looking for) then that may shed some light on what is taking so long.

Comment 10

[tyaremco]

(In reply to Andrew McCreight [:mccr8] from comment #9)
> You have a thousand tabs open, so some performance problems are expected. 
> It is unfortunate that unloaded tabs do have some overhead.

I don't expect performance problems in this case.  Comment 6 shows how that performance does not suffer globally, but per-window. Why should the mere existence of unloaded tabs have any performance impact on tab switching?

> 
> Is the lagginess just at startup, or is it ongoing?
> 

Ongoing.

> One thing that would be useful, if it is really GC and CC, would be to go to
> about:config and set javascript.options.mem.log to true, then look at the
> Browser Console.  

Don't the initial perf profiles I posted supersede anything that can be learned from javascript.options.mem.log?  The analysis in comment 8 points to the problem not being javascript.  Am I misunderstanding?

> Less than <2% of /total/ time is spent marking JS objects
> It seems that JS GC is not the primary culprit here.

Comment 11

[Andrew McCreight [:mccr8]]

(In reply to tyaremco from comment #10)
> Don't the initial perf profiles I posted supersede anything that can be
> learned from javascript.options.mem.log? 

The mem.log thing will give a high level overview of the work being done by the GC and CC.  For instance, are we actually collecting a lot of garbage, or just looking at a lot of stuff but not really freeing anything?

> The analysis in comment 8 points
> to the problem not being javascript.  Am I misunderstanding?

The option is rather misnamed at this point.  It also records activity of the cycle collector, which covers RunCycleCollectorSlice.

Comment 12

[Terrence Cole [:terrence]]

(In reply to tyaremco from comment #10)
> (In reply to Andrew McCreight [:mccr8] from comment #9)
> > You have a thousand tabs open, so some performance problems are expected. 
> > It is unfortunate that unloaded tabs do have some overhead.
> 
> I don't expect performance problems in this case.  Comment 6 shows how that
> performance does not suffer globally, but per-window. Why should the mere
> existence of unloaded tabs have any performance impact on tab switching?

Well, it does require us to track, draw, and handle events for 1000's of complex elements. Presumably, we optimized for the typical use case of 10's of tabs. It's quite possible that whatever structure we're using just scales poorly when you put 1000's of elements in it. I remember seeing a similar thread a few years on the linux kernel mailing list in which linux had similar pathological behavior when you tried to run 1000's of processes at once.

Comment 13

[tyaremco]

> Well, it does require us to track, draw, and handle events for 1000's of
> complex elements. 

When I select loaded tab #2, what tracking, drawing, or event handling is being done for unloaded tabs #3-1000? I could understand if I was moving tabs, opening tabs, or even scrolling the tabbar, but not simply selecting a loaded tab.

Comment 14

[tyaremco]

Below is an example of the output I get with javascript.options.mem.log true.  In this test I'm using  the Testing Method in comment 1.  

I need to stress that when I repeat the test I get between 1 and 4 GC and CC messages like those below.  It is not consistent.  However, repeating the same test in another window with two tabs, I do not receive any Max Pauses.



GC(T+687.7) Max Pause: 752.3ms, Total Time: 6440.0ms, Zones Collected: 1161, Total Zones: 1161, Total Compartments: 2718, Minor GCs: 151, Store Buffer Overflows: 5, MMU (20ms): 0%, MMU (50ms): 0%, SCC Sweep Total: 200.7ms, SCC Sweep Max Pause: 111.3ms, Allocated: 340MB, +Chunks: 0, -Chunks: 0
    Slice: 0, Pause: 241.7 (When: 0.0ms, Reason: CC_WAITING): Mark Discard Code: 26.5ms, Purge: 0.8ms, Mark: 172.4ms, Mark Roots: 171.9ms, Minor GC: 22.5ms
    Slice: 1, Pause: 41.2 (When: 342.8ms, Reason: INTER_SLICE_GC): Mark: 24.7ms, Minor GC: 14.1ms
    Slice: 2, Pause: 41.2 (When: 486.0ms, Reason: INTER_SLICE_GC): Mark: 23.4ms, Minor GC: 14.5ms
    Slice: 3, Pause: 41.2 (When: 643.4ms, Reason: INTER_SLICE_GC): Mark: 23.7ms, Minor GC: 15.0ms
    Slice: 4, Pause: 20.6 (When: 722.3ms, Reason: REFRESH_FRAME): Mark: 2.2ms, Minor GC: 16.3ms
    Slice: 5, Pause: 21.4 (When: 771.1ms, Reason: REFRESH_FRAME): Mark: 5.6ms, Minor GC: 13.2ms
    Slice: 6, Pause: 23.1 (When: 804.0ms, Reason: REFRESH_FRAME)
CC(T+690.2) max pause: 65ms, total time: 115ms, slices: 10, suspected: 844, visited: 7458 RCed and 6871 GCed, collected: 1099 RCed and 4123 GCed (4123|0|40 waiting for GC)
ForgetSkippable 20 times before CC, min: 5 ms, max: 892 ms, avg: 58 ms, total: 1178 ms, max sync: 0 ms, removed: 4294961712
GC(T+709.5) Max Pause: 404.8ms, Total Time: 4712.7ms, Zones Collected: 1160, Total Zones: 1160, Total Compartments: 2715, Minor GCs: 81, Store Buffer Overflows: 0, MMU (20ms): 0%, MMU (50ms): 0%, SCC Sweep Total: 151.9ms, SCC Sweep Max Pause: 81.0ms, Allocated: 338MB, +Chunks: 0, -Chunks: 0
    Slice: 0, Pause: 200.3 (When: 0.0ms, Reason: CC_WAITING): Mark Discard Code: 28.4ms, Purge: 3.6ms, Mark: 147.2ms, Mark Roots: 146.8ms, Minor GC: 5.0ms
    Slice: 1, Pause: 41.3 (When: 301.0ms, Reason: INTER_SLICE_GC): Mark: 34.4ms, Minor GC: 5.2ms
    Slice: 2, Pause: 41.3 (When: 443.0ms, Reason: INTER_SLICE_GC): Mark: 36.1ms, Minor GC: 3.3ms
    Slice: 3, Pause: 41.7 (When: 585.0ms, Reason: INTER_SLICE_GC): Mark: 34.6ms, Minor GC: 5.2ms
    Slice: 4, Pause: 11.2 (When: 662.6ms, Reason: REFRESH_FRAME): Mark: 3.7ms, Minor GC: 5.6ms
    Slice: 5, Pause: 12.3 (When: 719.1ms, Reason: REFRESH_FRAME): Mark: 3.3ms, Minor GC: 6.6ms
    Slice: 6, Pause: 41.4 (When: 832.1ms, Reason: INTER_SLICE_GC): Mark:
CC(T+711.9) max pause: 35ms, total time: 70ms, slices: 9, suspected: 981, visited: 7861 RCed and 3423 GCed, collected: 924 RCed and 694 GCed (694|0|151 waiting for GC)
ForgetSkippable 15 times before CC, min: 6 ms, max: 423 ms, avg: 48 ms, total: 730 ms, max sync: 0 ms, removed: 7228
GC(T+732.0) Max Pause: 817.4ms, Total Time: 5726.9ms, Zones Collected: 1160, Total Zones: 1160, Total Compartments: 2712, Minor GCs: 104, Store Buffer Overflows: 0, MMU (20ms): 0%, MMU (50ms): 0%, SCC Sweep Total: 167.3ms, SCC Sweep Max Pause: 74.1ms, Allocated: 337MB, +Chunks: 0, -Chunks: 0
    Slice: 0, Pause: 116.9 (When: 0.0ms, Reason: CC_WAITING): Mark Discard Code: 15.1ms, Purge: 2.7ms, Mark: 85.9ms, Mark Roots: 85.7ms, Minor GC: 3.0ms
    Slice: 1, Pause: 41.6 (When: 217.2ms, Reason: INTER_SLICE_GC): Mark: 36.5ms, Minor GC: 3.3ms
    Slice: 2, Pause: 40.6 (When: 359.2ms, Reason: INTER_SLICE_GC): Mark: 33.7ms, Minor GC: 5.6ms
    Slice: 3, Pause: 41.2 (When: 500.3ms, Reason: INTER_SLICE_GC): Mark: 34.3ms, Minor GC: 5.1ms
    Slice: 4, Pause: 41.6 (When: 642.3ms, Reason: INTER_SLICE_GC): Mark: 34.7ms, Minor GC: 5.1ms
    Slice: 5, Pause: 40.8 (When: 784.3ms, Reason: INTER_SLICE_GC): Mark: 33.9ms, Minor GC: 5.4ms
    Slice: 6, Pause: 40.8 (When: 925.3ms, Reason: INTER_SLICE_GC): Ma
CC(T+734.3) max pause: 113ms, total time: 149ms, slices: 8, suspected: 554, visited: 10121 RCed and 6362 GCed, collected: 2681 RCed and 2647 GCed (2647|0|11 waiting for GC)
ForgetSkippable 17 times before CC, min: 6 ms, max: 829 ms, avg: 68 ms, total: 1171 ms, max sync: 0 ms, removed: 4716
GC(T+754.0) Max Pause: 790.0ms, Total Time: 5602.3ms, Zones Collected: 1160, Total Zones: 1160, Total Compartments: 2711, Minor GCs: 104, Store Buffer Overflows: 0, MMU (20ms): 0%, MMU (50ms): 0%, SCC Sweep Total: 195.1ms, SCC Sweep Max Pause: 90.2ms, Allocated: 338MB, +Chunks: 0, -Chunks: 0
    Slice: 0, Pause: 115.1 (When: 0.0ms, Reason: CC_WAITING): Mark Discard Code: 15.3ms, Purge: 1.8ms, Mark: 85.5ms, Mark Roots: 85.2ms, Minor GC: 2.4ms
    Slice: 1, Pause: 40.8 (When: 216.2ms, Reason: INTER_SLICE_GC): Mark: 34.5ms, Minor GC: 5.0ms
    Slice: 2, Pause: 41.1 (When: 357.2ms, Reason: INTER_SLICE_GC): Mark: 33.7ms, Minor GC: 5.5ms
    Slice: 3, Pause: 40.7 (When: 499.0ms, Reason: INTER_SLICE_GC): Mark: 36.8ms, Minor GC: 3.0ms
    Slice: 4, Pause: 40.9 (When: 640.0ms, Reason: INTER_SLICE_GC): Mark: 36.9ms, Minor GC: 2.9ms
    Slice: 5, Pause: 41.3 (When: 781.2ms, Reason: INTER_SLICE_GC): Mark: 33.7ms, Minor GC: 5.6ms
    Slice: 6, Pause: 41.2 (When: 923.0ms, Reason: INTER_SLICE_GC): Ma
CC(T+756.4) max pause: 66ms, total time: 103ms, slices: 9, suspected: 417, visited: 7290 RCed and 3724 GCed, collected: 1038 RCed and 982 GCed (982|0|8 waiting for GC)
ForgetSkippable 20 times before CC, min: 5 ms, max: 801 ms, avg: 59 ms, total: 1193 ms, max sync: 0 ms, removed: 2050
GC(T+776.0) Max Pause: 666.4ms, Total Time: 5545.4ms, Zones Collected: 1160, Total Zones: 1160, Total Compartments: 2711, Minor GCs: 104, Store Buffer Overflows: 0, MMU (20ms): 0%, MMU (50ms): 0%, SCC Sweep Total: 177.5ms, SCC Sweep Max Pause: 87.4ms, Allocated: 337MB, +Chunks: 0, -Chunks: 0
    Slice: 0, Pause: 169.8 (When: 0.0ms, Reason: CC_WAITING): Mark Discard Code: 24.9ms, Purge: 3.8ms, Mark: 126.0ms, Mark Roots: 125.8ms, Minor GC: 3.9ms
    Slice: 1, Pause: 41.8 (When: 271.0ms, Reason: INTER_SLICE_GC): Mark: 34.9ms, Minor GC: 5.1ms
    Slice: 2, Pause: 40.5 (When: 413.5ms, Reason: INTER_SLICE_GC): Mark: 33.3ms, Minor GC: 5.7ms
    Slice: 3, Pause: 41.4 (When: 554.8ms, Reason: INTER_SLICE_GC): Mark: 34.6ms, Minor GC: 5.1ms
    Slice: 4, Pause: 40.7 (When: 697.0ms, Reason: INTER_SLICE_GC): Mark: 34.3ms, Minor GC: 5.1ms
    Slice: 5, Pause: 41.1 (When: 838.1ms, Reason: INTER_SLICE_GC): Mark: 34.4ms, Minor GC: 5.1ms
    Slice: 6, Pause: 40.6 (When: 985.3ms, Reason: INTER_SLICE_GC): 
CC(T+778.2) max pause: 46ms, total time: 72ms, slices: 7, suspected: 300, visited: 6270 RCed and 2771 GCed, collected: 92 RCed and 0 GCed (0|0|6 waiting for GC)
ForgetSkippable 20 times before CC, min: 5 ms, max: 677 ms, avg: 51 ms, total: 1022 ms, max sync: 0 ms, removed: 2474

Comment 15

[Andrew McCreight [:mccr8]]

Ah, so you are getting a bunch of GCs that have a max pause of almost a second, and are taking almost 6 seconds to run.  Unfortunately the GC information is being cut off for some reason so we can't see what the actual long pause is, but I assume it is going to be in sweeping, near the end.  The GC is running on every zone, which may be why it is taking so much time.

Comment 16

[Terrence Cole [:terrence]]

(In reply to tyaremco from comment #13)
> > Well, it does require us to track, draw, and handle events for 1000's of
> > complex elements. 
> 
> When I select loaded tab #2, what tracking, drawing, or event handling is
> being done for unloaded tabs #3-1000? I could understand if I was moving
> tabs, opening tabs, or even scrolling the tabbar, but not simply selecting a
> loaded tab.

I don't understand why changing the tab selection would be less expensive than any of those operations. Off the top of my head, at minimum it would have to do: hit testing to map mouse x/y to the right tab, updating the selection information, redrawing the changed elements, firing tab-leave and tab-enter events for all of your extensions, and that's just at the chrome level -- much more happens in the platform. Each of those is going to involve a running quite a bit of code. It seems that some of that code is structured in such a way that it causes us to trigger an all-zones GC /and/ forces large sections of that GC to happen non-incrementally.

Comment 17

[tyaremco]

(In reply to Terrence Cole [:terrence] from comment #16)
> (In reply to tyaremco from comment #13)
> > > Well, it does require us to track, draw, and handle events for 1000's of
> > > complex elements. 
> > 
> > When I select loaded tab #2, what tracking, drawing, or event handling is
> > being done for unloaded tabs #3-1000? I could understand if I was moving
> > tabs, opening tabs, or even scrolling the tabbar, but not simply selecting a
> > loaded tab.
> 
> I don't understand why changing the tab selection would be less expensive
> than any of those operations. Off the top of my head, at minimum it would
> have to do: hit testing to map mouse x/y to the right tab, updating the
> selection information, redrawing the changed elements, firing tab-leave and
> tab-enter events for all of your extensions, and that's just at the chrome
> level -- much more happens in the platform. Each of those is going to
> involve a running quite a bit of code. It seems that some of that code is
> structured in such a way that it causes us to trigger an all-zones GC /and/
> forces large sections of that GC to happen non-incrementally.

My thinking was that opening/moving tabs would cause a redraw/reposition of neighboring tabs.  These operations would not be necessary for tab selection so those tasks would be more expensive.

Comment 18

[Terrence Cole [:terrence]]

(In reply to tyaremco from comment #17)
> (In reply to Terrence Cole [:terrence] from comment #16)
> > (In reply to tyaremco from comment #13)
> > > > Well, it does require us to track, draw, and handle events for 1000's of
> > > > complex elements. 
> > > 
> > > When I select loaded tab #2, what tracking, drawing, or event handling is
> > > being done for unloaded tabs #3-1000? I could understand if I was moving
> > > tabs, opening tabs, or even scrolling the tabbar, but not simply selecting a
> > > loaded tab.
> > 
> > I don't understand why changing the tab selection would be less expensive
> > than any of those operations. Off the top of my head, at minimum it would
> > have to do: hit testing to map mouse x/y to the right tab, updating the
> > selection information, redrawing the changed elements, firing tab-leave and
> > tab-enter events for all of your extensions, and that's just at the chrome
> > level -- much more happens in the platform. Each of those is going to
> > involve a running quite a bit of code. It seems that some of that code is
> > structured in such a way that it causes us to trigger an all-zones GC /and/
> > forces large sections of that GC to happen non-incrementally.
> 
> My thinking was that opening/moving tabs would cause a redraw/reposition of
> neighboring tabs.  These operations would not be necessary for tab selection
> so those tasks would be more expensive.

Ah, that makes sense. My own intuition is that some algorithm underlying tab-strip management is super-linear in the number of tabs, in part because reflow and redraw are not likely in this situation. And I guess you already found that the culprit is the GC. I'll try to reproduce the slowdown locally and figure out what's going off the rails. Will probably be next week though because of the holiday tomorrow.

Comment 19

[Andrew McCreight [:mccr8]]

Ongoing work to reduce the number of zones we collect (bug 1052793 and bug 1110928) should also help a lot in this scenario.

Comment 20

[tyaremco]

Attachment: Gecko Profiler report on Nightly 38

I've attached a Gecko Profile for Nightly.  It's only a few seconds long so hopefully it's easier to interpret.

Clean profile, no addons.  The only change I made was to import a sessionstore.sqlite from another profile.  I've disabled e10s due to bug 1125578.  Hardware acceleration is on (but I experience the same symptoms with it off).


-- Testing Method --
I have 1000+ tabs in one window (A) and two tabs in another (B).  
The last two tabs in both windows are about:blank.  
All other tabs are in unloaded state.

- start profiler from window A
- switch back and forth between the last two tabs in window A about ten times
- focus window B
- switch back and forth between the two tabs in window B about ten times


-- Observations --
I'm not convinced that the major problem here is GC/CC.  

If I position the browser console (javascript.mem.log=true) so I can see it while I click on tabs, I do experience a longer delay right before I receive a GC/CC notice in the console. However, for the majority of clicks I do not receive any notices and there is still a noticeable delay for tab focusing in window A compared to window B.

In other words, I've _never_ been able to produce a situation where the duration from mousedown to tab focus in window A is equal to window B.  It's always longer and always reproducible.

Comment 21

[tyaremco]

(In reply to tyaremco from comment #20)
> Created attachment 8555673 [details]
> Gecko Profiler report on Nightly 38
> 
> I've attached a Gecko Profile for Nightly.  It's only a few seconds long so
> hopefully it's easier to interpret.
> 
> Clean profile, no addons.  The only change I made was to import a
> sessionstore.sqlite from another profile.  I've disabled e10s due to bug
> 1125578.  Hardware acceleration is on (but I experience the same symptoms
> with it off).
> 
> 
> -- Testing Method --
> I have 1000+ tabs in one window (A) and two tabs in another (B).  
> The last two tabs in both windows are about:blank.  
> All other tabs are in unloaded state.
> 

Total number of tabs was actually 704.

Comment 22

[Wayne Mery (:wsmwk)]

(In reply to tyaremco from comment #20)
> Created attachment 8555673 [details]
> Gecko Profiler report on Nightly 38
> 
> I've attached a Gecko Profile for Nightly.  It's only a few seconds long so
> hopefully it's easier to interpret.
> 
> Clean profile, no addons.  The only change I made was to import a
> sessionstore.sqlite from another profile.  I've disabled e10s due to bug
> 1125578.  Hardware acceleration is on (but I experience the same symptoms
> with it off).

since that bug is closed...

No doubt your performance issues will reduce with e10s enabled with dom.ipc.processCount > 1.
Splitting the memory usage across multiple processes has a very pleasant effect.

Comment 23

[Graham Perrin]

How are things with release 56 and pre-release 57?

Comment 24

[mirh]

So.. Putting aside this is quite evidently stale, I don't know what special change was baked in FF76 (or maybe it's just lots of reflows having been fixed), but UI performance skyrocketed.
It's almost *too* fast now, for how I was used to it.

Comment 25

[Mayank Bansal]

Closing this based on the OP's comment.