I've switched to Firefox 3 times in the last 2 years, and each time I've been forced back to Chrome by horrendously (2-3x worse) bad battery life on my MacBook, caused by some variant of this bug which Mozilla seems determined not to fix. https://bugzilla.mozilla.org/show_bug.cgi?id=1404042
The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
261–270 of 281 posts
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#262I've switched to Firefox 3 times in the last 2 years, and each time I've been forced back to Chrome by horrendously (2-3x worse) bad battery life on my MacBook, caused by some variant of this bug which Mozilla seems determined not to fix. https://bugzilla.mozilla.org/show_bug.cgi?id=1404042
What makes you think they're determined not to fix it? A commit that significantly improves the situation landed in nightly a week ago.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#263I've switched to Firefox 3 times in the last 2 years, and each time I've been forced back to Chrome by horrendously (2-3x worse) bad battery life on my MacBook, caused by some variant of this bug which Mozilla seems determined not to fix. https://bugzilla.mozilla.org/show_bug.cgi?id=1404042
What makes you think they're determined not to fix it? A commit that significantly improves the situation landed in nightly a week ago. https://bugzilla.mozilla.org/show_bug.cgi?id=1429522
the fact that they've not fixed it for literally years, despite having hundreds or thousands of reports?
I'll believe they have a fix when I see it with my own eyes, which probably won't be for another 6 months because switching my browser workflow isn't something I want to do every couple of weeks to try out a new nightly with big promises.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#264Earlier quoted context omitted.
I seem to remember that some GPU acceleration under Linux was disabled voluntarily, on both Firefox and Chrome, because they actually ran much slower than CPU, probably due to bad drivers.
It is slower not due to drivers, but due to how the browsers[1] compose the final webpage. It does that using CPU, not GPU as on other operating systems, so hardware video decoding would involve moving the compressed video to GPU, waiting for it to decode, moving the decoded video back to RAM, do the composition, and then move the result back to GPU for display. For hw decoding to have sense, GPU composition is neede…
GPU layer composition was available in Firefox for ages, long before WebRender. It just was not enabled on Linux by default due to fear of bad drivers. But anyone who heard about it or asked about performance on various forums knows about layers.force-enable in about:config.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#265Earlier quoted context omitted.
JSC has had a set of large metabenchmarks like JetStream2 for a while. We have been the fastest for a while but V8 is gaining, so the current advantage is significant but not earth shattering. The last time V8 had their own benchmark, they retired it right after we beat them on it and made a post saying that benchmarks are bad because people cheat on them. Around that time I stopped seeing google.com claim that I sho…
I've always wished I could actually benefit from JSC without dropping a couple thousand dollars on a macbook and having to put up with the world's worst keyboard, because your browser team kicks ass :) At least you're pressuring Mozilla and Google to step up their game on runtimes!
it's not Mac exclusive. WebKitGTK uses JSC too
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#266Earlier quoted context omitted.
I was perfectly fine with Chrome's usability until I started getting a `Hold Command + Q` to quit` prompt on my Mac. Before then, I hadn't even considered the possibility that an application could block me from quickly and easily quitting out of it. Now I have to hold the key combo or double tap it to quit Chrome, and it is the only application I have to do that for. It's so annoying.
This bugs me big time, I wonder what was the decision behind such inconvenient UX.
How is it inconvenient? It prevent accidental quits!
I use ctrl-q as my shortcut key in tmux. I can't count how many times I accidentally sent that into the wrong window :) I consider showQuitWarning in Firefox a necessity.
IMO, no application ever should quit from one key combination without confirmation.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#267Earlier quoted context omitted.
About a decade ago I needed an embedded scripting language in a c++ project and chose JS. Embedding SpiderMonkey was a matter of copying all files in the `js` subfolder of the Firefox sources into my project, and calling into it was peanuts. The classes were well named, easy to use and easy to learn. Did this somehow change?
Nope. JSC is even better in that regard - it’s API and ABI stable so you can just link to the[1] system install and use it [2]. [1] on Linux there are multiple (although technically it could be made to have a single lib for qt,gtk,wx... [2] ok, actually using the C API is very very clunky :-/
There are often multiple installs of spidermonkey too (IIRC recently there was an effort in FreeBSD Ports to consolidate everything onto the latest couple versions)
The most (in)famous consumer of that is polkit :) but also GJS
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#268Had no idea their interpreter was C++ under the hood. Excellent article fro the Mozilla team as always.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#269Earlier quoted context omitted.
I'm fairly certain it does it already.
It says its using the GPU but if you look at the cpu time required to play a 1080p video within firefox vs playing the same video with mpv www.mpv.io : a lightweight player that among other things can transparently stream any url understood by youtube-dl It uses 20x as much cpu as mpv. For purposes of comparison this is like Toyota selling a car that goes just as fast as your Ford so long as you are OK with only gett…
I use mpv on my laptop to get more out of the battery and to stop the fan annoying me.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#270Earlier quoted context omitted.
Couldn’t you say much the same thing about Firefox as a whole?
I think so, but with the Javascript VM i think this is more clear, to the spot. As far as i know, the web rendering engine of Firefox in C++ were pretty old, coded in old c++ style. So in this particular case a rewrite would have some leverage. The thing is, in the end, i dont know if this part C++, part Rust codebase wont start to create more problems than it solves. Should the layout and rendering engine be rewritt…
A project is done when no one is willing to work on it anymore.
We are all employees, not owners. Decisions that look good on paper won't stop people from finding a new job if the consequences of that decision are more than you want to deal with. And won't the new person want to rewrite it anyway? Now we have a rewrite being done by a person who has no idea why all the weird code is so weird.
So the trick isn't rewrite or no rewrite, the trick is how do we make the rewrite give us things we couldn't have without it. Employee retention is important but as you say that's not enough for the board or the users.
And rewriting in phases avoids the worst aspects of rewrites, which are sometimes undertaken in bad faith (intentionally on unintentionally). Some groups I've seen seem to enjoy the fact that you get to write a lot of code without thinking too hard, and management doesn't pester you about deadlines too hard for the first six months. Those are not good reasons for a rewrite, and they usually end pretty badly. But by then the developers have been at the company long enough that the duration looks good on their resume.