I'm sorry, I do not understand from the article what the Baseline Interpreter is or does. It keeps the Baseline Compiler from having to compile so many functions by turning some sections into bytecode first?
The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
231–240 of 281 posts
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#232Earlier quoted context omitted.
Fixing this would be like eight steps forward: https://bugs.chromium.org/p/chromium/issues/detail?id=137247 The annoying part is that hardware acceleration works on chrome OS, so we know the support is buried in there somewhere.
Google closed that as Won't Fix, they are very opinionated and steadfast in their opinion as an organization. I doubt they will take Linux outside their own walled gardens seruously, Google has already shown their indifference to us Linux users.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#233Earlier quoted context omitted.
I solve this by using Firefox for all web browsing, and Chrome for gmail/gapps/anything by google. It sucks that we have to do that, but I can't entirely blame them for making their own products work better on their own browser.
Just like you can't blame Microsoft for making ActiveX work best on Windows.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#234Earlier quoted context omitted.
Given that Linux has 2% desktop market share (let's be generous) and Firefox has 10% (let's be generous the same way), that would mean that Linux has potential to be 20% of Firefox users. Is that something you are going to ignore? Many executives would sell their families for less opportunity.
The big difference is that those executives would be getting money out of those 20% customer base. I seriously doubt that those 20% Firefox users even consider doing a $1 donation.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#235Something I'm curious about is why JS developers don't have the option to send along some of this information themselves; type information, JS bytecode, etc. Given that we often have it on hand already (TypeScript) or could integrate it into our build process (webpack). Obviously plain JS needs to still work without all that, but it could be a compelling point of optimization for large-scale apps. Perhaps the JS byte…
Deno[0], a project from the original author of Node, will natively run TypeScript, so I'm hoping it will have some of those sorts of optimizations. [0] https://github.com/denoland/deno
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#236Earlier quoted context omitted.
That's fair and I now know more. I'm not convinced that this is the biggest issue with JS engines/browsers, but I certainly have more evidence against me :). It's interesting how many of those are labeled OOB. Does that mean that we're talking JIT flaws that allow OOB access to memory? Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? I wonder what the performance i…
> Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? What's the difference between the two? Many JavaScript exploits abuse the interaction between strange features of the language to get around bounds checks (often, because a length was checked but invalidated by later JavaScript executing in an unexpected way, or a bound not forseen as needing a check) leading to an…
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#237Earlier quoted context omitted.
As the gp said, async/await is rarely used in hot loops, so it would probably never get jit-ed in a real webpage.
I don’t agree given that async iterator can be iterated. But I’m ok if SpiderMonkey folks thinks so ;)
Maybe there are people (ab)using the async stuf do do something else, but at least it's not really common.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#238Earlier quoted context omitted.
Gmail is really crazy slow on Firefox, it’s such a deal breaker. I have regularly 30s to load the web application, it’s closer to 2-5s on Edge with the same setup (same ad blockers, etc).
I suspect this is because chrome supports WebSQL while Firefox does not.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#239Earlier quoted context omitted.
As the gp said, async/await is rarely used in hot loops, so it would probably never get jit-ed in a real webpage.
I don’t agree given that async iterator can be iterated. But I’m ok if SpiderMonkey folks thinks so ;)
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#240Earlier quoted context omitted.
Pcwalton! While I agree that most synthetic benchmarcks are mostly not representative for the real world, there is a benchmarck suite for real world. That is benchmarcking most used ALEXA websites. It's named TP 5 and TP6, mozilla use it internally (e. G to measure progress on stylo) Why is the real world (TP5/6) not public?? Phoronix has never used it, mozilla has never publicly published benchmarcks. I guess they f…
Did you look at the raptor dashboards? Let me help you: https://treeherder.mozilla.org/perf.html#/graphs?timerange=2...