perf shows #1 offender is calls to read_hpet. why is this thing spending so much time reading system timer?

and why is seamonkey the only thing on my system affected by whatever recent library change caused this?

hyc1: I can't help but wonder if GLXVsyncThread is related

yeah that's my suspicion too

"whatever recent library change", what have you figured out so far, what might or might not be related? Does this affect old versions too (i.e. issue in library or elsewhere, not in SeaMonkey), or only newer versions?

also, official builds from SeaMonkey, or distro builds or both?

official seamonkey builds

and this happens with no page open and no extensions installed? happens with a brand new profile too?

I was running 2.53.16 fine before. then after rebooting for a recent ubuntu update, it started lagging.

I upgraded to 2.53.17 just in case that would help but it's not made a difference

if you have a way, try to get a list of the packages that may have caused this

any way to get a list of changed/upgraded packages in the time window when the update happened?

I dunno how. any way to find a list of the recently installed stuff in chrono order?

heh same question

can't help there, I'm afraid I only know how to do that for Gentoo

Bug 1592530 looks similar

there have been a few times when I start up and there's no lag. but sooner or later it hits and then stays slow.

CPU usage never gets very high here. I'm now in offline mode and it idles at 0-1%. but still lags.

why can't bugs and issues be well behaved and be reproducible and happen always at the same specific time

lol

and, while we're at it, why don't they come with a full map of where they are and what causes them

hyc1 what CPU, gpu and memory amount?

this is a legion 7 laptop, ryzen 5950, nvidia something or other. 64GB RAM.

the system is loafing along

firefox is running smoothly

ah I see further down in that bug report this may be GPU driver related?

and what video driver

frg_Away: I'm wondering if this could in any way be also related to that "seamonkey downloads stop when in another virtual console" issue

(that one's bug 1713051)

so the dgpu is nvidia, using nouveau. but I'm usually on the igpu, which is amd.

Fx is now using Webrender and totally different gfx stack. Nvidia and Linux is not really my favorite combination either. Only on Windows.

(ok, it was IRC, not a download)

just checked glxinfo etc, definitely using the AMD igpu right now

hyc1: "read_hpet" should be normally implemented as a physical "direct" read from the correspond register. Linux kernel allows all the processes to read (read-only) such types of registers for performance purposes (just by mapping the correspond physycal addresses to the address space of the process).

I suspect that for some reason after updating your system, instead of direct reading, a function call of a similar action (from glibc) was used (some kind of fallback method or something like that, etc.). And it affected performance.

Could be even something sandbox related. Or some kind of a specific system security levels (kinda alien applications are not allowed to something etc.)

a couple oddities...

#1, about: has the version listed in a "SeaMonkey box". that box is a link, making selection of the version number more difficult (needing to do an alt+drag kind of thing to select it)

#2, about:addons, & about:addons with a specific extension selected. once again selecting (highlighting) said extensions name/version is difficult. version number itself, you may not even be able to get?

Also something interesting can be obtained in /sys/devices/system/clocksource/clocksource0/ (ie. available and current clocksources).

(it for hyc and hyc1 :) )

therube: at least as a workaround perhaps about:support is better suited for selecting or copying

heh. i'm glad that we (& most every other sensible program in the world) have about:

FF does not ;-)

I think my first complaint about FF lacking something was noticing that they did not include the website navigation bar