Significant performance degradation after upgrade to v28

[therube]

Off-topic:

Counted overall tab amount more precisely - actually, I have 125 tabs in 8 windows.

https://addons.mozilla.org/en-US/firefo ... sion-0.1.3

[badnick]

I confirm thiss issue, at least for me. Here is a test made by me for "real world"- a couple of sites (PM 28.2.2 vs PM 27.9.4 both clean profiles , no addons).
How you can see PM 28.2.2 is very sluggish.
https://streamable.com/yanzu

[Moonchild]

You're also comparing apples and oranges.

The very thing that makes Pale Moon 28.* less performant is also what makes it more compatible: more than doubling the functional support for JS functions and features.
Also, improving performance by removing unnecessary asynchronicity will be a long road. It can only go up from here.

[CodeLurker]

Whatever this problem is, at least it is reproducible now. Finding a browser that doesn't suck has been bothering me for a LONG time - since e10s, actually. I love that I can run pre-WebExtensions versions of SessionManager, Forecast & Bookmark Here 2 in Basilisk (although FF has apparently recently deleted all pre-WE plugins at their addons site). Still, I have to restart Basilisk about 10X/day, because of recurring performance degradation. I'm running version 2018.12.18 from a zip from the main download at the site. However, when I run the JetStream benchmark in Basilisk, It fails on the notorious bigfib.cpp intermittently. (I found the Github issue.) At first when I ran it, it failed on the third pass. I then restarted Basilisk in Safe Mode, and with no other tabs open and no addons enabled, ran the test. Basilisk just plain froze, on an earlier JS test. I ran it again, and it failed bigfib.cpp on the second and third passes. I then ran it outside of Sandboxie (vers. 5.26), and it completed fine once. I waited about 5 min., and ran it again, and it failed bigfib.cpp on the third pass.

I'm running Win7 32-bit Home on a Core I5-2500k with an Asus mb and 8 gB RAM. I just haven't gotten around to re-installing windows 7 yet.

Interestingly, I just downloaded the portable version of PaleMoon (vers. 28.2.2), and ran the JetStream test. It passed with flying colors! I just can't get my favorite plugins to run. If you can build a browser with PM's JS processing, and Basilisk's addon compatibility, I will proudly dub it the only browse in existencer that doesn't suck!

[Moonchild]

There is no difference between Basilisk and Pale Moon in terms of JavaScript, since they are both using the same platform code (UXP) where the JS engine lives.

EDIT: I ran JetStream through Basilisk-release just to verify, no issues seen.

[CodeLurker]

I just ran JetStream twice in PM, waiting 5 min. between them. No fails. It's a fresh extraction, except I've sorta got Session Manager and ForecastFox installed on it.

I tried a fresh extraction of Basilisk from the zip, and ran it once. It failed on the second pass: bigfib.cpp. Same versions as above.

Perhaps there's some subtle difference in the JS engine versions being used between the versions of PM and Basilisk I tested.

Maybe it'll encourage you up to know the one time Basilisk got through all three passes, it got a 178.56. PM got 173.84 & 173.45. FF 62 got 164.21. An older yet Iron Browser got 160.14.

[Moonchild]

The problem is not lack of encouragement
The problem is seeing that there is something to fix, to begin with. Which there doesn't seem to be.

[CodeLurker]

Interesting. If GreaseMonkey for PM is enabled, PM never finishes the first test: 3d-cube. If ForecastFox for PM is enabled, same thing. Only if both are simply disabled in addons, and the browser is restarted, the test runs without problems. All the rest of the addons were also disabled for this test (I'm up to five in PM, now). If I restart it in Safe Mode, it never finishes 3d-cube. Same versions as above.

[Isengrim]

It's generally a good idea to disable all add-ons before running these kinds of tests. Safe Mode actually isn't a good idea in this case, because it disables certain graphical capabilities in addition to add-ons. Your best bet is creating a fresh temporary profile and running the test with that profile.

Off-topic:
Edit: My results on my Win 10 machine. I would hazard a guess that lower numbers on this test can probably be attributed to hardware differences.

[Pepita]

Moving to another browser; 5 windows opened, and a memory issue starts asking to close all programs; till to 28 version I managed almost the double.
Sluggish is the right definition
Thanks anyway

[CodeLurker]

It's generally a good idea to disable all add-ons before running these kinds of tests. Safe Mode actually isn't a good idea in this case, because it disables certain graphical capabilities in addition to add-ons. Your best bet is creating a fresh temporary profile and running the test with that profile.

I see your point. I ran my freshly extracted Basilisk; and noticed it had all the plugins my other version had. It was picking up my AppData profile. I then ran the freshly extracted Basilisk from a CMD window running as a different user this time: Administrator. I ran it with "basilisk -profile test". It had no Extensions, although many Plugins. I had opened no Web pages. I ran the test, and it failed on the first test, first pass, on bigfib.cpp. I made a screencap this time.

Since bigfib.cpp is not a graphics-oriented script, but a number crunching and object intensive one, maybe it has nothing to do with my video card (GeForce 9800GT).

[mrnhmath]

Just ran JetStream on Basilisk x86. No errors.

[CodeLurker]

Just ran JetStream on Basilisk x86. No errors.

Version? OS? Bits?

[mrnhmath]

Just ran JetStream on Basilisk x86. No errors.

Version? OS? Bits?

2018.12.18 x86, Windows 7 x64

[CodeLurker]

There's the difference. x64. I guess that'll move up when I install a 64-bit vers. Basilisk & Palemoon are trying to support x86 thus far, however.

One difference vs. Linux: at least in MSVC, the compiler is still x86 (as of VS 2015, anyway), even on a x64 vers., compiling a x64 prog. It should just be a matter of flipping a compiler switch. Of course, if memory corruption were going on, or array boundaries were being overrun, it can make things erratic. Arrays sometimes leave unused padding at the end, to more efficiently align on word boundaries, e.g. - hence different layouts on x64. However, since both are x86 progs., that wouldn't explain it; unless the OS is laying out allocations differently by itself. It might be that x86 emulation on win7 x64 might be better than win7 itself. It could be differences in win7 updates. Mine's SP1, but some recent updates aren't on there. It still seems quite a mystery to me. It seems we could use more win7 sp1 x86 tests. Also, are others on win7 sp1 x86 not experiencing performance degradation when leaving a few .js rich pages up for hours, or getting/not getting clean runs of JetStream?

[Moonchild]

One difference vs. Linux: at least in MSVC, the compiler is still x86 (as of VS 2015, anyway), even on a x64 vers.

You're quite mistaken.
VS2015 uses 64-bit compilers (so does VS2013, by the way). It can cross-compile to 32-bit and that is what is being used by Pale Moon, but the compiler itself is 64-bit.

I can see about putting this intermittent issue to the test with a pure x86 Win 7 install, but that might take some time to set up.
EDIT: I still had a Win7 x86 VM laying around, so that was a quick and easy test. No issues seen, no errors on bigfib.

At this point I'm thinking it may be something specific to your system, e.g. an issue with floating point rounding in your CPU or maybe one of the spectre patches has thrown a spanner in the works on your Intel box. Since it's intermittent even for you, it's likely a timing issue -- which may also be a flaw in the test itself!

[GogrillaMincefriend]

Howdy everybody - joined up to post this as I've also been experiencing odd performance issues with v28; only in windows (my linux systems, including a dual boot on the same hardware, are fine), and only with my "main" browser. I've got a couple of portable installations of PM v28 that don't suffer from this issue even though all three are running the same extensions. Windows 7, 64bit OS, 64bit executables.

Long story short, there seems to be something *very* funny going on with memory allocation of my "main" PM installation (i.e. the one in C:\Program Files\Pale Moon). I frequently run into many short-lived performance problems with it, occasionally getting the "not responding" error (although I have a pretty beefy windows machine so these are short lived), but mostly feeling like the program was pulling itself out of swap or something. On looking in task manager I see something odd; PM seems to be constantly trying to shrink down its private working set whilst the total commit stays the same. Attached is a screenshot from task manager showing the total commit at ~1.7GB but the private working set at a mere ~200MB. Going back into the browser and doing things will apparently "repopulate" the private working set, but as this happens the browser runs like a dog.

Going to about:memory and measuring will bring the private working set almost up to the entirety of the commit size - and for a few minutes after that there'll be no more lag... but then private working set gets depleted again, and the lag starts creeping back again. I've attached a quick'n'dirty perfmon screenshot tracking the working set of me doing just this. I opened about:memory and hit "measure" at approx. 09:55:00, the private working set shoots from about 2GB to 4GB and then slowly empties again. Any time the private working set ends up building back up again (presumably pulling in memory from somewhere else), PM is very sluggish.

I'm not sure if stuff is actually getting pushed out to swap, but that's exactly what it feels like. Oddly enough, the longer the browser has been running for, the less extreme the lag spikes become; my pet theory on this is that it's due to memory fragmentation meaning less of the working set gets pushed out, but I don't know how one goes about proving it.

You can also see in the task manager pic the two "portable" instances. As you can see, these have a private working set that is much closer to the total commit, and these never suffer from the sporadic slowness that dogs my main browser. The memory for those behaves as it always seems to have done in the past. I'm curious as to whether these are built with different compiler options that might affect the memory allocation. Also, are the portable binaries able to be used as a drop-in replacement for the official binary...? If it works I'd be interested in trying it out.

I'd be interested to see if anyone else in this thread can turn on the extra columns in task manager and see if they observe the same behaviour; I've not seen this before in any other application so I thought it was worth mentioning with respect to this problem. Likewise if anyone more knowledgeable than me has any debug fripperies they'd like me to look at (or just to shut the hell up ) please let me know.

[CodeLurker]

OK. I guess they haven't done an all 32-bit compiler for some time then. I should have remembered I had to run on a 64-bit machine to compile 64-bit code.

At this point I'm thinking it may be something specific to your system, e.g. an issue with floating point rounding in your CPU or maybe one of the spectre patches has thrown a spanner in the works on your Intel box. Since it's intermittent even for you, it's likely a timing issue -- which may also be a flaw in the test itself!

Floating point error doesn't explain why I need to restart my browser ~10x/day. It's not like I'm the only one running a Core I5-2500k. Sometimes, if I'm sticking to sites that seem to have well-behaved code, it doesn't seem to do it at all. I just think the JetStream results may be a manifestation of the problem causing that. As to malware, I run in Sandboxie and use Hostsman with the HPHosts malware lists among others. I did have one malware due to a pic I opened from IRC; but thought I quickly got rid of it. Maybe it's as likely an explanation as any, but I'm doubtful. That's the only single instance, if memory serves, of malware I've had in several years, and that was years ago. I've also had a similar performance degradation with FF too, even FF x64 on a Win10 VM. FF Quantum was getting better about it, but still doing it - but they ruined too many important plugins. SeaMonkey just kept crashing on me. Not a bit of anything like that from Iron Browser (Chromium variant) or IE, ever. No slowdowns in any other program; Internet enabled or not.

It might possibly my GeForce driver. I saw a post where a new driver fixed his problem, but I think mine are up to date. Mine are from nVidia, not the mfr, tho. It may be worth trying in an x86 and/or x64 VM on this machine, and/or another. Also, that issue I referenced in my first post on this thread could detect the problem that someone made a temporary build with a fix, and there was a way to see that prob. in dev tools. I might be able to see the same thing going on here. I'm encouraging up to several others with frequent, many times per day, performance degradation on Win7 x86 to post their problem here; in addition to the last post about performance problems dogging a non-portable PM. I'd like to hear from a few who are not, when running natively. I'm torn between reformatting my HD and installing x64, and trying to nail this sucker that's been biting me in the ass for years, across all FF derivatives; and has probably been doing the same to others. If its a driver, a windows update patch, bugs in FF, SM, PM & Basilisk and/or their plugins, malware (I'm skeptical of that - I run a fairly tight ship when it comes to malware), I can't tell. I'd like to know what, but I'll only poke around with it some while longer. It's good to hear that it isn't doing that for everybody in Win7 x86. There is light at the end of the tunnel for me.

I'm usually good in situations like this. I'm the guy who asked for red wavy underlines for misspelled words and helped them fix Emmet in Notepad++; and I posted a lot when Netbeans kept going unresponsive after games would change display resolution. They finally got that fixed. It was a bug in Java itself. Those and others, without actually doing any coding (apart from my stuff). This is certainly a vexing one. Sporadic ones are the worst. Ones that don't manifest on all hardware - harder yet.

PS: Nice work, GogrillaMincefriend. Some near guru-like sh**te there.

[yami_]

Off-topic:
Actually Microsoft provides IA-32, AMD64 and ARM cross-compilers, an IA-32 compiler and an AMD64 compiler.

[Moonchild]

Please don't take my answer to one question (jetstream) to be an answer to a completely different issue (having to restart the browser).