Waterfox 56.x performance sometimes suffers when a memory-hungry tab is unloaded or closed #424

grahamperrin · 2018-02-04T12:21:49Z

Environment

Waterfox 56.0.3.5 a.k.a. 56.0.4 on FreeBSD-CURRENT.

Multi-process disabled.

Around 1,500 tabs (1,474 at the time of writing).

ZFS,

$ gpart show
=>       40  976773088  ada0  GPT  (466G)
         40     409600     1  efi  (200M)
     409640       2008        - free -  (1.0M)
     411648    4194304     2  freebsd-zfs  (2.0G)
    4605952   16777216     3  freebsd-swap  (8.0G)
   21383168  955389952     4  freebsd-zfs  (456G)
  976773120          8        - free -  (4.0K)

$

KDE Plasma 5, XRender, compositor disabled or enabled (scale method: crisp).

c.2012 HP EliteBook 8570p with 16 GB memory.

Examples of memory-hungry might include:

https://riot.im/app/#/room/#mozilla_#firefox:matrix.org, where the signed-in user of Riot has joined that room and many others.

In brief

Sometimes, after an unusually 'hungry' tab is unloaded or closed, Waterfox will:

stop responding for a few seconds
respond for a while
again, stop responding for a few seconds
again, respond for a while

… and so on.

Re: #423 I find no benefit from memory.free_dirty_pages in these situations.

The pattern of (mis)behaviour might be more likely to occur if there's some use of the swap device before unload/closure.

During these periods it 'feels' slightly as if there's thrashing of the hard disk drive e.g. swap. However that sense of things is limited to the browser (generally, Plasma feels OK) and from experience with other systems, I doubt that thrashing is a significant factor.

I've been paying more attention to this type of behaviour in recent weeks … gut tells me that it's not new behaviour (e.g. no difference between 56.0 and 56.0.4).

Workaround

As far as I can tell:

about:memory
free memory

– simple enough, but the minimisation takes some time.

Notes

@MrAlex94 given those two vector-im/riot-web issues, and this long list of enabled extensions:

2018-02-04 12:00 about:support.txt

– you'll probably want me to attempt reproduction of the issue with far fewer extensions. Or just close this issue :-) I'll not be offended.

@jbeich if you have any insight I'll be grateful. I'm painfully aware that:

my (bleeding edge) -CURRENT is significantly outdated
my mix of three repos including (bleeding edge) Area 51 is eyebrow-raising

– so yep, folks are likely to treat those two things (plus my mix of extensions) as laughable/risky but FWIW the whole caboodle works amazingly well for me (with one notable exception, which is off-topic from Waterfox).

$ date ; uname -v
Sun  4 Feb 2018 11:57:27 GMT                                                                                                                   
FreeBSD 12.0-CURRENT #0 r320869: Mon Jul 10 13:57:55 UTC 2017     [email protected]:/usr/obj/usr/src/sys/GENERIC

$ pkg -vv | grep -A 30 Repositories                                                                                                            
Repositories:
  FreeBSD: { 
    url             : "pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
  area51: { 
    url             : "http://meatwad.mouf.net/rubick/poudriere/packages/head-amd64-kde5-import/",
    enabled         : yes,
    priority        : 7
  }
  poudriere: { 
    url             : "file:///usr/local/poudriere/data/packages/current-freebsd-ports-kde",
    enabled         : yes,
    priority        : 5,
    mirror_type     : "SRV"
  }
  trueos-base: { 
    url             : "http://pkg.cdn.trueos.org/unstable/amd64-base/",
    enabled         : no,
    priority        : 0
  }
  trueos-packages: { 
    url             : "http://pkg.cdn.trueos.org/packages/unstable/amd64/",
    enabled         : no,
    priority        : 0
  }
$

Last but not least, I have a long screen recording. Link to follow.

The text was updated successfully, but these errors were encountered:

grahamperrin · 2018-02-04T12:40:58Z

Screen recording: https://photos.app.goo.gl/p0TZJXsN8PE7UZop1

Viewing time: twenty-six minutes (with some acceleration; the recording period was longer). Hint: don't watch the whole thing for fun! It covers a variety of issues.

The last four minutes are probably enough to get an idea of the performance issue. Maybe watch from 08:38:36 on the clock (23:00 on the timeline).

Generally – throughout the recording: wherever you see me moving the mouse/pointer around in circles, aimlessly, that's usually to indicate that I'm waiting for the browser to respond.

On-screen notes that I took during the recording:

FireTitle kicking in … no ' - Waterfox' suffix to any title.

Tab Groups. For the selected group – University of Brighton – there are too many tabs. It's a mixture of tabs from other groups. Workaround …

Riot web app is a work in progress, not optimised. Observe the increase in VM usage.

I get a sense that Waterfox performance plummets if I either unload, or close, the tab for Riot.

OK, it's not necessary to forget closed tabs for freedom/minimisation of memory to succeed after ~~unloading~~ closing the tab for Riot.

jbeich · 2018-02-04T14:31:38Z

Stylo: true (enabled by user)

Probably this. When you unload a tab its memory is garbage collected. Not sure which Firefox version fixed Stylo to not lock up a tab on GC.

grahamperrin · 2018-02-04T15:42:08Z

Thanks!

I probably began the recorded session with layout.css.servo.enabled false – there's a toggle to true at 0:28 on the timeline, I can't recall whether I toggled again after that.

Now false. I'll quit Waterfox then test a session with no change to true …

Note to self: on a handful of occasions in the past, I noticed a sudden leap in VM usage, and the size of the leap was as if I had opened a second or third instance of Riot.

grahamperrin · 2018-02-04T17:25:16Z

Another screen recording: https://photos.app.goo.gl/zGT2CrQetErjFhUT2

Viewing time: fourteen minutes.

Stylo was disabled throughout the session. No noticeable difference – as before, periods of Waterfox not responding after unloading the Riot tab.

I also experimented with extensions.legacy.enabled false. In the absence of Auto Unload Tab (a legacy extension) I didn't know how to unload, and I wasn't inclined to test a Firefox Quantum-compatible alternative, so I simply closed the Riot tab then again:

periods of Waterfox not responding.

… in the past, I noticed a sudden leap in VM usage, and the size of the leap was as if I had opened a second or third instance of Riot.

I reproduced that behaviour. The Riot tab:

first load
first unload
second load
second unload
third load nearly complete, Waterfox with just five tabs using 24 G virtual memory, a frame from the recording:

On-screen notes that I took during the recording:

OK, watch the VIRT figure when I reload the unloaded tab for Riot …

Boom. And if Waterfox behaves now as it did a few minutes ago, the figure will drop (back down to ~10 G) after the reload is complete …

… this could easily be mistaken for a leak. Is it? (I guess not, if it drops down.)

Hmm. No drop back down this time. A whopping 18 G ish. And rising, but I suspect that it'll drop … eventually. Or maybe not.

Again … check out the lack of response.

Now, a second reload (after the second unload) …

(I did click it, there was some delay before Waterfox appeared to respond.)

Mmm. Delicious 24.3 G and …

(Whilst I wait for that struggle to complete, note to self: Stylo off, memory.free_dirty_pages true. I wonder whether there'll be these leaps if I set memory.free_dirty_pages to false.)

That was one leap down from ~25 to ~18 and I guess that freedom of memory will end with the VIRT figure at ~10 G.

11.1 G. Close enough.

Now with both layout.css.servo.enabled and memory.free_dirty_pages ~~and servo~~ false …

… still, periods of non-responsiveness.

Now let's try with legacy extensions disallowed. Oh, my poor browser, without those lovely extensions :-(

Hmm. I forgot, Auto Unload Tab is a legacy extension. I'll have no idea how to unload the Riot tab.

Incidentally Conex (to the right of the address field) is not intended for use with anything less than Firefox Quantum.

Here they are again, with legacy extensions disallowed: periods of non-response after closing the Riot tab.

Responding well after freeing memory. The same was true when legacy extensions were enabled.

Final test, I'll make memory.free_dirty_pages true once more then again close the Riot tab. Again, periods of non-response.

Qualitatively that felt worse. A long period of non-response followed by the drop in use of virtual memory. (Was that drop the result of memory.free_dirty_pages true? I wonder.)

grahamperrin · 2018-02-06T01:42:02Z

A quick comparison with Firefox Quantum

With Firefox 58.0 I visited a https://riot.im/app/ room, plus other pages in a few other tabs, then tried to:

discard the Riot tab with Discard Tab
unload (or should I say discard?) the Riot tab with Tab Unloader.

As far as I could tell, neither extension succeeded.

grahamperrin · 2018-02-25T22:49:37Z

Maybe related:

Mozilla bug 1441041 - memory not freed after ceasing to visit some types of content

– with the 'hungry' content that's at step (6), I see behaviour that's comparable to the Riot app in this issue.

grahamperrin · 2018-05-25T03:24:38Z

Meta, tracking: #538

Recent dd92030 (2018-05-15) fixed memory.free_dirty_pages in Waterfox 56.x · Issue #423 … and re: #423 (comment), I gained an early impression that the commit might have reduced the frequency of this issue 424. In particular:

Things do feel better, but that might be because recently I've not done much to force use of swap.

However, after testing for a few days:

Waterfox 56.2.0 is still, sometimes, very painful after use of affected sites.

This morning after an extended period of poor responsiveness, it was necessary to use about:memory to manually minimise use of memory with, as usual, the consequent improvement in performance.

This incident is significant because:

there's zero use of swap space
use of memory prior to minimisation was nowhere near the red (viewed with htop(1)).

grahamperrin · 2018-06-19T06:48:05Z

Touch wood, no longer reproducible with Waterfox 56.2.1 on FreeBSD-CURRENT 👍

This screen recording began after closing a tab to Riot:

2018-06-18 06:52.mp4.zip

(Side note: the apparent split-second completions of about:memory minimisation of memory are almost suspiciously fast, compared to the waiting periods that I found in the past.)

One more screen recording to follow.

$ pkg info waterfox | grep Version
Version        : 56.2.0.53
$ date ; uname -v
Mon 18 Jun 2018 21:46:44 BST
FreeBSD 12.0-CURRENT #5 r335024: Wed Jun 13 11:04:24 BST 2018     root@momh167-gjp4-hpelitebook8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC

2018-06-19 07:45 about:support.txt

I'll check for symptoms on a different machine, one that's suitably powerful. Today, if I can … hopefully close this issue …

grahamperrin · 2018-08-15T06:32:39Z

Briefly:

still an issue
usually reproducible when closing a window to memory-hungry Riot app
with my minimal everyday profile, re: https://redd.it/96s5c2 if I allow javascript.options.gc_on_memory_pressure true (the default), then (after a period of occasional limping) there's a remarkable drop in use of memory and the limping seems to continue after the drop.

grahamperrin · 2019-05-27T09:44:20Z

I haven't found this type of performance problem in a long while.

Today I pushed things quite hard, a busy Waterfox session restored after opening two virtual machines and a variety of other applications:

– Waterfox using 11.6G virtual memory (no reduction) after closing a window to Riot.

1.81/16.0G swap used.

Moments after the first screenshot, there was a significant reduction. Around the amount that I associate with Riot. Garbage collection in response to memory pressure, I guess.

Later, Waterfox using 5,748M virtual memory:

Throughout this period, performance of single-process Waterfox 56.2.10 was OK.

I rarely use multi-process Waterfox Classic, when I last did so I sensed that it was less smooth that single-process – in an environment that was free from memory pressure. I imagined that it would become quite jerky under pressure.

grahamperrin closed this as completed May 27, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Waterfox 56.x performance sometimes suffers when a memory-hungry tab is unloaded or closed #424

Waterfox 56.x performance sometimes suffers when a memory-hungry tab is unloaded or closed #424

grahamperrin commented Feb 4, 2018

grahamperrin commented Feb 4, 2018

jbeich commented Feb 4, 2018

grahamperrin commented Feb 4, 2018

grahamperrin commented Feb 4, 2018

grahamperrin commented Feb 6, 2018

grahamperrin commented Feb 25, 2018

grahamperrin commented May 25, 2018

grahamperrin commented Jun 19, 2018

grahamperrin commented Aug 15, 2018

grahamperrin commented May 27, 2019

Waterfox 56.x performance sometimes suffers when a memory-hungry tab is unloaded or closed #424

Waterfox 56.x performance sometimes suffers when a memory-hungry tab is unloaded or closed #424

Comments

grahamperrin commented Feb 4, 2018

Environment

In brief

Workaround

Related

Notes

grahamperrin commented Feb 4, 2018

jbeich commented Feb 4, 2018

grahamperrin commented Feb 4, 2018

grahamperrin commented Feb 4, 2018

grahamperrin commented Feb 6, 2018

A quick comparison with Firefox Quantum

grahamperrin commented Feb 25, 2018

grahamperrin commented May 25, 2018

grahamperrin commented Jun 19, 2018

grahamperrin commented Aug 15, 2018

grahamperrin commented May 27, 2019