I will just go back to Chrome or give Edge a proper try.
1 Like
…with a flamethrower?
5 Likes
well that would be the best way to try a lot of things… 
4 Likes
Ok, I got curious enough to really try to get a more apples-to-apples test for my own peace of mind. I closed out all my firefox tabs (after saving them, of course), restarted FF and chrome, and opened the same set of tabs in both browsers. It’s not entirely an even comparison since I have two addons in FF and none in chrome.
For my initial test set of 8 tabs in 2 windows (according to task manager, with all the processes added up), chrome is using 885M ram, while firefox is using 1.51G ram. So, roughly 600MB difference.
Loading up a third window with 14 of my original set of tabs in both browsers, I got: 2.06G in FF, 1.64G in Chrome. The difference has dropped a bit.
With my original full set of 40 tabs in FF, I was sitting at 2.2G usage.
I’m not quite motivated enough to load all 40 tabs in both browsers to compare, but I’ll leave the set I have currently open overnight to look for changes.
At least initially, based on this rough comparison, it does look like FF on my system is using a lot more memory initially, but less per additional tab. YMMV, and (as I said) this obviously isn’t a completely equal test.
4 Likes
I have had task manager open for quite awhile now. I am up in used memory for all tabs the more I use each one and response time is getting worse.
1 Like
Based on watching the CPU column the 2 main tabs are the forums here and at the other place both at about 500MB each. The other tabs are gmail, yahoo mail, and feedly. I tend to close out other tabs when I am done.
2 Likes
The general trend is up… for all tabs, Discourse is just the most used ones.
1 Like
I dunno. I didn’t use it often cause it was a memory hog at one point which was why I had been using Chrome for years.
ETA and the only other choice was IE which was a no fucking way that is gonna happen.
2 Likes
I haven’t used FF heavily enough in the last year or two to say. But @kxkvi up above is reporting more or less the same thing.
2 Likes
Sorry, I meant multiprocess. Firefox has, for as long as I remember, been multi thread. Basilisk is a fork of FF55 and will not use Electrolysis.
Edit:
The aim of Basilisk is to support all extensions, so they’re going to stagnate and not benefit from the speed increases in 57 onward.
1 Like
Update on my test up above after doing a bit more normal browsing with my test set of tabs and leaving it for the night:
Firefox ram usage has dropped to 1.91G
Chrome ram usage has risen to 1.91G
…I’ll be honest, that was not the result I was expecting. Just to be sure, I went through on both browsers and checked each tab to be sure each was updated (getting new threads on open twitter feeds, this site, etc). After that step, Firefox was still holding steady, but Chrome had risen to 2.08G. It (very) slowly started to drop back downward when I left the browser alone.
It’s looking as though, on my configuration, for long-term browsing, there’s probably not a big difference between the two.
4 Likes
And starting over even fresher as I got reboot patch last night.
2 Likes
Now I’ve got just 3 tabs open: gmail inbox, this page, and the Washington Post front page. Firefox is using ~1.17GB and six tasks. Just for fun I printed the WashPost page to PDF, and also saved it as an HTM file. (I made sure to navigate to the bottom of the web page first, to load all the images.) The pdf file is 4 MB, and the HTM file is 241 KB.
So is Firefox prefetching things to make it faster? Is that what a lot of the memory is used for?
4 Likes
Welp, I saw that NoScript was finally available in FF57, so I upgraded. Mistake. I should have read the fine print… a couple of the other extensions that I thought had been ported already are only “in the process” and after looking at the API docs, it’s not going to be possible to port that functionality. Pity they couldn’t fix it, we had such high hopes for XUL back in the day. Trying out Waterfox now.
3 Likes
Do you have any links to the relevant info?
Anybody missing Tree Style Tabs, it’s been ported to Web Extensions.
https://hacks.mozilla.org/2017/12/webextension-tree-style-tab/
2 Likes
Can anyone explain what xul and webextension can do, and what xul did that webextension can’t do?
Because I’m going to need to know if Firefox 57+ can eventually meet my accessibility needs, or if one of the forks is a better bet, unless there’s another browser that can meet my needs-- such as not getting punched: fuck Opera, fuck Sleipnir, fuck Google Maps…
Unfortunately, only Firefox 56 contains any migration tools, Firefox 52 esr won’t contain migration tools for those of us who need to wait for adequate keep-sites-from-hammering-our-brains tools.
P.S. https://bugzilla.mozilla.org/show_bug.cgi?id=1422910
P.P.S. Not all my tools will work yet, but my user styles will. It’s just that the Stylish migration was screwed up. I transferred to Stylus instead, and they’re working. I think my user scripts are gone even in 52.
1 Like
Is anyone on Firefox running Ad Nauseum?
Is is any good? The concept seems cool.
2 Likes
Marja,
As I understand it, the difference is essentially the following.
With XUL-based add-ons, you could do anything you wanted that Firefox’s own code could do itself, which was effectively unlimited, subject to passing through critical examination in the submissions queue before being posted to addons.mozilla.org. With an XUL add-on, the add-on’s code was mixed in with, interacted with and possibly partially replaced the code of Firefox’s own UI. The add-on had similar powers over the contents of web pages shown in tabs.
With WebExtensions-based add-ons, you (as the author of an add-on) can do nothing except that which is allowed through the WebExtensions API. Which is a lot, because it starts with (aiming for/achieving) parity with whatever Google Chrome can do, and adds some, namely whatever was needed by the people writing the most popular add-ons, in some priority order, limited by Mozilla developer time and added as they could get to it. But in general, the WebExtensions API allows doing things more to web pages and less to the Firefox UI, because that was one of the philosophical underpinnings of the new direction with WebExtensions.
By analogy with firewalls, which you’ve probably touched at some point: the policy with XUL add-ons was simply ALLOW, while the policy with WebExtensions is DENY,ALLOW, denying all operations then allowing some specific ones, the ones in the API.
I haven’t written any code with WebExtensions so I don’t know what’s in the API. This is just my general understanding based on what people have said and written about WebExtensions as it was coming onto the scene. It wouldn’t take many detailed questions about WebExtensions before I’d just be like ::shrug::. If anyone knows better, please clarify. But, if you don’t need to customize the Firefox UI much, but do need to customize what you see in web pages, there’s a good chance people could write add-ons doing what you want. It depends what you want.
I think that answers the first half of your question but not the second half.
5 Likes
An interesting limitation is that webextensions can’t affect Reader/Readable View.
P.S. Also they can’t create their own pages for editing, and Stylish/etc. and Greasemonkey/etc. can’t add lists of user styles and user scripts to about:addons. Stylus now keeps its list in its preferences. Greasemonkey now hides its list, only accessible by rummaging through Firefox’s libraries.
3 Likes