Maybe I'm missing it, but it says it was originally twice as slow as JS, than it says they did optimizations, then no comparison on the final outcome?
https://web.dev/case-studies/google-sheets-wasmgc#the_final_...
> The final result
> After all these optimizations, the final WasmGC version of Sheets achieves a calculation performance approximately twice as fast as JavaScript, representing a fourfold improvement from the starting point of the initial WasmGC version.
It's not an especially rigorous or intellectually honest article. It's a good example of how software development differs from other disciplines. The sleights of hand used in this piece are something that ideally would be rooted out in peer review.
You're comparing JVM bytecode as a compilation target for Java programs vs using JS as an alternative bytecode for Java programs. Unsurprisingly, the former wins. Who knew.
It's an extremely timely and interesting topic.
The performance of a third compilation target - JVM bytecode provides a useful baseline.
You're right: the article is comparing compilation targets for Java programs (or rather, one specific Java program in this case study). That's my point: despite that being what the article actually is, it's written like it's comparing Java programs to JS programs—the performance that a Java program can achieve versus the performance of a comparable JS program written to give the same results. But again, it's not comparing those. It's comparing how well they can compile Java, in Java source files, to JVM bytecode (or Wasm) and execute it on the corresponding VM versus how well they can get those Java source files to compile and run on v8 and various other JS runtimes. It's an analysis that simply doesn't show what is suggested by the authors' comments (e.g. "The challenge: JavaScript" and "Why is JavaScript slower than Java?" or anywhere that they refer to the (nonexistent) "JavaScript version").
Very sloppy and irresponsible use of language throughout. The whole article is a mess of confused thinking (at best, that is—the alternative is deliberate malfeasance).
The javascript version does exist! The fact that it's produced by a compiler doesn't undermine it's existence.
What's interesting here is not that it's slower than the equivalent running on the JVM but that it was _faster_ than a version compiled to wasm.
Well written and useful article if you would like to learn about what type of optimizations are effective in targeting the wasmgc runtime.
The JS was converted to Java and at that time was _at worst_ 5% slower. This might be a shock to you that J2CL is actually good enough to get the same performance as hand-written JS but it's been measured.
There was a similar effort done where the Docs Android app began to run on Java instead of J2CL output and I guess you should be surprised to learn that it was actually slower and significant work had to be put in to make Java running in the JVM faster than that Java (via J2CL) running within a JSVM.
Then that's worse. Because it means that the misleading way the article is written is deliberate.
> This might be a shock to you that J2CL is actually good enough to get the same performance as hand-written JS but it's been measured.
This is such an obnoxious comment when it doesn't have to be, and it's orthogonal to the issue at hand—which is that a Java program compiled to one or more object files that are nevertheless ECMA262-compliant so that it can run on V8 is still a Java program, in the same way that a when you compile a Java program to JVM bytecode, it doesn't stop being a Java program.
There is no "the JavaScript version". There is only the Java version built for different compilation targets. It's not possible to frame it any other way and still be rigorously honest about the results presented here.
(And it's telling that nobody taking issue with my criticism here, and who have proferred a defense of the article that amounts to equivocation, is willing to defend the other passage that I called out that is exemplary of the { Confused XOR Dishonest } way that this article communicates its message. <https://news.ycombinator.com/item?id=40820423>)
Google Sheets was released in 2006 and "Written in JavaScript" [1].
Around 2014 the codebase is mostly converted to Java. At this time the Java version and JS version's performance are measured and the Java version won't be allowed to launch if it's >5% slower across many use cases.
Note: The Java code isn't emulated by the browser. It's literally converted into a JS source file by GWT and your browser runs it just like any other JS file.
Note: This means the "Java" performance and "JavaScript" performance is equivalent.
Note: Rust is 2015 and full of lifetime markers [3] (i.e. not nearly as ergomatic as it is today); might even have green threads then too.
Around 2018 (?), GWT was replaced by J2CL. Similar story with performance rules.
Note: Not only is the file provided to your browser JS code, the JS file might contain handwritten JS source code for certain "Java files" as opposed to the J2CL output for that file.
Around 2023, J2CL is semi-replaced by WasmGC and WasmGC was 2x faster than the JavaScript being ran by the browser. That generated JS has a similar performance to completely handwritten JS so it's entirely honest to say WasmGC is 2x as fast as JS because
1. It is. It doesn't matter that the JS comes from transpiling Java files; open up a network tab and you'll see it's `.js` files.
2. Transitively it's better than the original handwritten JS files.
---
> And it's telling that nobody taking issue with my criticism here, and who have proferred a defense of the article that amounts to equivocation
No, it's just that you're using jargon to mean different things than other people use that jargon for and getting confused when things don't make sense in your state of the world.
It's a "JS version" because it's the version that is JS code. Much like how the output of J2ObjC produces the ObjC version.
[1]: https://en.wikipedia.org/wiki/Google_Sheets
[2]: https://en.wikipedia.org/wiki/Google_Web_Toolkit
[3]: https://en.wikipedia.org/wiki/Rust_(programming_language)
Although the only important thing is that WebAssembly is 2015 [2] so there's pretty much no reason to convert to Rust to target WebAssembly when neither of them were actually released.
[1]: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
Super specifically, https://github.com/rust-lang/rust/pull/18967, on Nov 21, 2014, is when it was actually removed.
"For example, they had a core data structure in Sheets which was blurring the lines between arrays and maps. This is efficient in JavaScript, which automatically models sparse arrays as maps, but slow on other platforms. ""
"Of the optimizations they found, a few categories emerged:
Replicating core optimizations that already existed in the Java Virtual Machine (JVM) and in V8.
Using highly optimized browser APIs.
Removing JavaScript-specific coding patterns"
For example, they point out that they got 40% improvement by adding devirtualization to the compiler. Java by its nature likes to add a whole bunch of virtual method calls. Java devs primarily rely on the JIT to fix that up (and it works pretty well). Javascript relies similarly on that sort of optimization.
WASM, on the other hand, was built first to compile C/C++/Rust code which frequently avoids (or compiles away when it can) virtual method calls.
I imagine this isn't the only issue. For example, I'll guess that dealing with boxing/unboxing of things also introduces a headache that wouldn't be present in similar C/C++ code.
In short, it just so happens that a lot of the optimizations which benefit JS also benefit Java. The one example where they did a Javascript optimization was prefering Maps and Lists over PoJos.
We had a pretty awesome team of people working across the entire stack optimizing absolutely everything. The blog post only talks about the three optimizations that made the biggest difference.
Go also has a WASM target which runs pretty slow compared to its native binaries. GC extensions might help but as far as I can remember, Go's memory model does not fit the WasmGC so it might never be implemented.
now explain if it's higher performance of JS or WAT
Edit: In a different blog post :
https://workspace.google.com/blog/sheets/new-innovations-in-...
"Building on improvements like smooth scrolling and expanded cell limits in Sheets, today we’re announcing that we’ve doubled the speed of calculation in Sheets on Google Chrome and Microsoft Edge browsers,"...
I dont use Google Sheet but I wonder how far apart are their new implementation compared to Native Microsoft Excel.
The idea of incremental calculation of formulas that don’t need to be put in a particular order is still genius but the grid is so Apple ][. Maybe the world doesn’t know it because it spurned XBRL but accounting is fundamentally hyper dimensional (sales of items > $100 in the afternoon on the third week of February in stores in neighborhoods that have > 20% black people broken down but department…) not 2-d or 3-d.
Having the wrong data structures is another form of “garbage in garbage out”. I have though many times about Excel-killers, trouble is they have to be something new, different and probably specialized, people know how to get answers with Excel even if they are wrong, plus Excel is bundled with the less offensive Word and Powerpoint so a lot of people are paying for it either way.
Personally I want a spreadsheet that does decimal math even if there is no hardware support except on mainframes: I think a lot of people see 0.1 + 0.2 |= 0.3 and decide computers aren’t for them.
Displays 0.3:
"=0.1+0.2"
Displays 3E+79:
"=(0.1+0.2)*1e80"
This question suggests it uses floats: https://stackoverflow.com/questions/74542790/google-sheet-yi...
I live in excel sadly and it's all been downhill since excel 2003
as for better math calcs, yeah excel isn't perfect for true accuracy of decimal math but that rarely matters in 99.99% of use cases - if you need really accurate math you use R/Python/etc.
if you need something for the masses, visicalc/lotus/excel is the solution
I was involved in this work (happy to answer any questions). Overall we started from a large slowdown compared to JS, worked hard, and ended up with a large speedup over JS of around 2x. So right now it is a big improvement over JS.
That improvement required work across the codebase, the toolchain, and the VM. Most of it is not specific to Java and also helps other WasmGC projects too (like Dart and Kotlin). We are also working on further improvements right now that should make things even faster.
I'm interested more in learning how to work within wasmgc. Do you have any resources you'd point to for someone looking to pick it up?
https://v8.dev/blog/wasm-gc-porting
See in particular the "getting started" section near the end:
https://v8.dev/blog/wasm-gc-porting#getting-started
At a lower level the overview in the WasmGC github repo is very good:
https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
(I remember you from your work with asm and emscripten and the various ports you did, which I played around with)
No specific question(right now), I just want to say, I admire your work.
Yeah, I was involved here on the toolchain side. We did a lot of work on the Binaryen optimizer for WasmGC.
1. How is the landscape of wasmGC browser support? Given it's relatively new is it OK to use this and ship production apps now? How does sheets handle older/unsupported browsers?
2. In Google IO the Workspace team mentioned they'd leverage Kotlin Multiplatform to achieve use cases like this. I see Sheet's using the in-house J2CL compiler but is there cases where KMM is used to target WASM - in sheets or docs? What are your thoughts?
https://webassembly.org/features/
Chrome (and other Chromium-based browsers) and Firefox have had WasmGC enabled for a few releases now. But Safari doesn't yet last I heard.
Sheets can serve a JS version to browsers without WasmGC, since they can compile the same code to either JS or Wasm.
About Kotlin, I know they have a working WasmGC toolchain that works very well, so personally I think it is a good option in general. But I don't know offhand about current users or plans.
I'll add that browser Google Sheets and native Microsoft Excel are the fastest versions available (of each product).
But yes I'd be curious to see how the web version of Excel does it.
While you technically can run it on ChromeOS through the Android emulation, it's still a mobile app and you're far better off running the web version.
Yet excel still limits the number of rows to 65536 or so.
Even a million seems embarrassingly puny these days, considering a webpage can have a million checkboxes rendered in only a moment.
> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
Any serious Excel user has a PC.
One of the few places remaining where Windows > Mac
And Microsoft would rather push everyone to the 365 Web subscription, than keeping selling native Excel, which by the way, nowadays uses plenty of React Native code instead of pure C++, exactly because of code portability to Office 365.
They only made these changes yesterday.
https://github.com/google/j2cl/
And that now includes a Java to WasmGC compiler, called J2Wasm:
https://github.com/google/j2cl/blob/master/docs/getting-star...