Thanks for clarifying! I should give Firefox a try again, when I tried last time it wasn't good enough. Chrome's devtools had many features of timing and performance which were absent or not good enough last time I tried.
That's a good point. I was simply speaking from a usage standpoint, not for development. Also, I suspect you're talking about javascript speed -- I was mainly addressing non-javascript rendering. Chrome feels basically instant, while Firefox's rendering takes an extra 300-500ms.. just enough to feel really sluggish.
i just want to say, Firefox is seriously fast now, while Chrome continues to get slower [1].
my 10M datapoint uPlot benchmark runs in half the time, for both pure js (fake data gen) and canvas workloads (chart rendering). check out the console in [2].
however, i'm still waiting for the performance assessment in devtools to improve so i can get an easy summary as i can in Chrome.
also, better default form input styling would be nice. it's so...Windows 98....but i'm on Windows 10. :\
I am primarily a Firefox user, but there is one small feature of Chrome that I cannot live without. In the dev tools performance tab Chrome has button to reload a page and automatically start measuring performance as a result of that page start.
Also, when I look at the Firefox performance graph its super over the top powerful. So much so that I frequently have trouble understanding it. I suppose I just need to find a tutorial to better help explain how to interpret that data and filter it to what I need to better improve my JavaScript code.
Thanks. I'm not sure about setTimeout, I can't imagine it's slow, but it might be something with context switching.
There's probably things you could do in the VM to optimize performance for Firefox. If you developed the VM in Chrome, typically people optimize for it Chrome. I can usually get relatively close performance if I tweak a few things here and there for both Firefox and Chrome.
Although, I think Firefox's main performance comes from JIT-ing, which you've totally lost if your running in a VM. The above example is a loop, which would usually perform great, but you've lost the JIT. That may be a reason.
I don't think major 2 is objectively true. Firefox is faster than Chrome in every benchmark test I've seen for two years now.
As for minor 4, the blame is with developer. The API that was eliminated was EOLed long before they removed it, and it looks like he's doing some security violation https://github.com/gigobyte/ui-stack/issues/6
Won't argue about the performance, you might very well be right and I cannot prove anything.
Feel free to expand on what features you still miss in Firefox that exists in Chrome though.
Looking from the other side Chromes extension API looks like a toy compared to Firefox, even after Mozilla "nerfed" it. (And ours is improving while Chrome is actively trying to remove even some of the most used features from theirs.)
I love Firefox but some JS heavy demos etc. just don't work fast enough. I hate that I know exactly why. It's because they were only ever tested on Chrome during development.
Tried it again last week. Still slow, I'm afraid, despite Mozilla literally inventing a new kind of programming language to speed it up!
A lot of it has to do with design, though. ie. when opening a new window, Chrome draws the window instantly and then fills in the UI, while Firefox waits until the window is completely built to display it. Even though they become usable at roughly the same time, Chrome responds instantly to the command while Firefox exhibits zero sign of life for hundreds of milliseconds.
Chrome dev tools are equal as powerful, and regarding the other comment about speed. I have tried the new firefox and chrome still flows better. The reasons posted here are not sufficient, sounds like the firefox users are just loyal.
Agree! I wonder why the performance in Chrome is so much worse than Firefox? I constantly have ~100ms higher values in Chrome than Firefox. Maybe the author is using Firefox for development, so the test is optimized for Firefox.
Chrome also seems to show red dots every ~3 seconds for me, while Firefox shows no red dots, strange.
This is great news! I tried to switch to firefox to do my (frontend) development in, but I noticed serious slowdowns compared to Chrome with multiple tabs open. Going to give this another try!
Chrome and Firefox performance should be closer, at least in Chrome 72 and 73. I think the comparisons may have been done without trap handler support in Chrome (virtual memory tricks for fast memory bounds checks).
I wish this were true but certainly on Linux I don't find this to be the case. I periodically try switching to Firefox and always end up back on Chrome for performance reasons.
Features wise I prefer Firefox (containers are amazing, extra privacy features/blockers by default nice, the new picture in picture for video is nice, dev tools have a lot of cool extra features etc), but Firefox often struggles and stutters for me, whereas I rarely have issues with Chrome.
The devtools are a good example, sometimes just having them open on a page I am developing slows everything down. Closing/re-opening the tab seems to fix it for a bit but then it just starts to happen again, Chrome's devtools are always snappy. Similary if I want to inspect an element on a page Chrome never has a problem doing it instantly, Firefox has to think about it for a while.
In general everything that uses the GPU I find far faster in Chrome. The other day for instance I was working on a d3 SVG visualization that strained Firefox but was no problem for Chrome, canvas performance is similar but not as bad in my experience. The most common offender is trying to watch a video: in Firefox everything slows down and the fans spin up, in Chrome no effect.
It is also true that all Google services that I am unfortunately tied to (GMail, Maps, Calendar etc) are snappy in Chrome and like molasses in Firefox...
I've had Firefox block more js/elements than Chrome and sometimes I think other bits of the page are busy waiting for some event that will never happen.
reply