Re: firefox resource hog

[Ignatios Souvatzis <ignatios%cs.uni-bonn.de@localhost>]

On Mon, Jan 09, 2023 at 10:22:35AM +0100, ignatios%cs.uni-bonn.de@localhost wrote:
> On Mon, Jan 09, 2023 at 09:20:07AM +0100, Benny Siegert wrote:
> > On Sun, Jan 8, 2023 at 12:16 PM Riccardo Mottola
> > <riccardo.mottola%libero.it@localhost> wrote:
> > > I too notice things are slower on NetBSD with Firefox and ArcticFox seems to do better, so the hint that "threads" and "processes" might be an issue is a hint.
> > 
> > I think this has something to do with the relative slowness of
> > synchronization primitives in NetBSD, which in turn has to do with the
> > HZ setting in the kernel. For instance (not directly related), every
> > time the Go runtime needs to to a short wait -- say, 100 ns -- it ends
> > up being a 5-10 ms wait. Because Go and Rust are a lot more
> > multi-threaded, they use these primitives a lot more.
> > 
> > All this to say: if you want faster Firefox, ultimately you need to
> > look into making Rust run faster on NetBSD.
> > 
> > The difference is obvious if you compile lang/rust on NetBSD vs. Linux
> > on the same machine.
> 
> Hm. with:
> 
> ps -sux | grep -i -c firefox
> 
> 359	ff91esr
> 409	ff102esr
> 
> on NetBSD-9.3_STABLE
> 
> same machine (10GB Lenovo W701), same workload
> (one element, one zabbix, one zammad, one wikipedia page, one proxmox )
> 
> My colleagues tell me that FF105/ FF108 on Linux don't do that
> (about 11 or 12 threads).

Scratch the last statement.

I've checked on my own Linux laptop and verified with one colleague.
11/12 are processes not threads, we both see around 250 threads for 
the above workload with FF 102.6.0esr.

	-is

-- 
Ignatios Souvatzis, Chief IPv6 enabler		RFC 6540
Gemeinsame Systemgruppe b-it + Informatik	Tel. +49 228 73-60701
gsg%cs.uni-bonn.de@localhost