Why Google Sheets ported its calculation worker from JavaScript to WasmGC

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?

I didn't know WasmGC was a thing yet!

https://developer.chrome.com/blog/wasmgc/

Some things that are at first glance surprising is that GC'ed languages might ship a smaller binary, because they don't need to include the code that manages memory. (The example here was Java.)

When WasmGC is widely adopted, we might hopefully see some languages adopting it as a target instead of JS. I'm thinking of Clojure and Dart specifically but there are plenty of other languages that might benefit here.

This could also have an impact on "edge computing" (isolates etc.) down the line.

It’s perhaps telling that they had an initial prototype which was 2x slower, then talk about specific optimization strategies but never share the updated overall speed comparison.

Anyone here actually bothered by the speed of the core calculation engine of Google sheets?

I'm bothered by the sluggishness of the UI, but I've never typed '=A1+A2' in a box and found it takes too long to get an answer.

Even if it did, I'd kinda like million row X million column sheets to somehow be server side and my machine simply views a local window, and calculations happen locally if feasible with locally available data, or server side otherwise.

They also mention that “there are cases where browser APIs are backed by optimized native implementations that are difficult to compete with using Wasm … the team saw nearly a 100 times speedup of regular expression operations when switching from re2j to the RegExp browser API in Chrome” if so how they call RegExp from WasmGC or viceversa? 100 times speedup for native web apis is not something you can ignore, that’s the important lesson here, not everything compiled to wasm will result in a speed again

Nice to hear from teams building with Wasm GC. They bring up the "shared everything" proposal [0] for enabling heap objects to be shared across the threads. In addition to this, I'd like to be able to share the contents of a packed array, such as a (ref (array i8)), with the host. Right now, only Wasm memory objects have ArrayBuffer access in JS. Providing the same shared access to packed GC arrays would unlock things like WebGL, WebGPU, and Web Audio for Wasm GC applications. I made a "hello triangle" WebGL program with Wasm GC awhile back, but there's no way that I know of to get acceptable throughput when working with GPU buffers because they have to be copied byte-by-byte at the Wasm/JS boundary.

[0] https://github.com/WebAssembly/shared-everything-threads/blo...

As somebody who is not familiar with how garbage collection is implemented at the low level, can somebody explain why WasmGC is needed on top of Wasm?

For example, isn't CPython a C program and hence can just be compiled to Wasm, including its garbage collection part? Does garbage collection usually depend on OS specific calls, which are not part of C standard?

It is not entirely clear from the article, but apparently, they still use Java for their calculation engine. And then transpile it into JavaScript. Which makes me wonder whether instead of porting this code base to WasmGC, a partial rewrite would have helped the project’s maintain ability in the long run. Rust seems like a potentially good candidate due to its existing WebAssembly backend.

WasmGC is useful for many other projects of course. But I wonder how painful it is to maintain a Java code base, which is not a great choice for client-side web apps to begin with. I remember using GWT back in the days - and that never felt like a good fit. GWT supported a whitelisted subset of the Java standard library. But the emitted Javascript code was nigh on impossible read. I don’t remember if Chrome’s developer tools already had source map support back in those days. But I doubt it. Other core Java concepts like class loaders are equally unsuited for JavaScript. Not to mention that primitive data types are different in Java and JavaScript. The same is true for collections, where many popular Java classes do not have direct counterparts in JavaScript.

They forgot to mention the final speedup:

>The initial version of Sheets Wasm showed calculation performance roughly two times slower than JavaScript.

>[...]

>Implementing speculative inlining and devirtualization—two very common optimizations—sped up calculation time by roughly 40% in Chrome.

So the only numbers we get are 2x slowdown and the 1.4x speedup, which makes it sound like it's still slower. I'm sure thats probably not the case but it is a strange way to write an article advertising wasm.

Also, I'm a bit confused about which language this was actually written in before the wasm switch. Was it always written in Java and transpiled to JS? It doesn't seem that way from the article:

>Removing JavaScript-specific coding patterns.

>they had a core data structure in Sheets which was blurring the lines between arrays and maps. This is efficient in JavaScript

which doesn't make sense if they were writing it in Java and transpiling to JS.

Was it transpiled to JS only once in 2013 and then developed in JS from there? In which case why go back to Java?

With infinite effort, a company with infinite resources made something that is already objectively fast enough twice as fast!

They are right though that wasmgc might have a bigger impact than wasm alone. Lots of attention is deservedly paid to Rust but people use garbage collected languages more.

This is the kind of cool cutting edge web development that google excels at. Hopefully there are some down stream effects that help more tools move to the web. Good work!

It seems this is not a full rewrite of the calculation engine, so it’s hard to compare the performance of JavaScript against WASM.

Has anyone rewritten a performant calculation in that way from JavaScript to WASM? I’m curious to what the performant gap is, and whether browser optimizations are closing or widening that gap.

I love how we are slowly back to Applets and related plugins.

WebGL | WebGPU + WasmGC => Flash!

Maybe they can finally make Google Sheets, etc... off-line stand alone app.

Slightly off topic, but since the GenAI push google has started investing heavily into its devtools again, namely Sheets and Colab. Either that or these teams are just that good! If you haven't checked out the recent "Tables" update to Sheets, I highly recommend it -- probably the most meaningful improvement in years.

When will Safari have WasmGC?

I'll need to look into this but if anyone knows: is this available (easily) as a standalone package somewhere; think using the engine from a CLI without needing or contacting Google Sheets at all.

> 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. So they had to rewrite the code in a more platform-agnostic way. This is another thing the team like about WebAssembly: it makes it easier for multiplatform applications to get good performance on the web. You don't have to bend your whole application to the idiosyncrasies of JavaScript.

Uh, that's a terrible example. It's not an example of anyone forced to "bend their whole application to the idiosyncrasies of JS" at all. It's almost the opposite

Someone wrote the code they wanted to write, whether in good taste or not, and the JS runtimes that the product was tested on handled it efficiently (to their credit!); i.e., the authors of those JS runtimes had to bend their implementations to accommodate the idiosyncrasies of people who were/are writing code like that.

This is really cool, I wonder what .NET to wasmGC would be like.

WasmGC: Revenge of the JVM

This is a bit of a tangent but it always annoys me when content has no published date next to it. There's a tiny "last updated" date at the bottom. But how do we know if this is a new article or one from a few years back? With technology moving so fast it can significantly change the context in which you read an article.

It's great to see Java Web Start finally being used in anger 24 years after its initial release.

Why is javascript slower than java?

uhhhh I don't think there is actually a real answer in that paragraph that compares PERFORMANCE of JS to JAVA.

that explanation is completely unhinged?

is this why all my gsheets scripts started failing out of nowhere today

Google finally got NaCL/Pepper into the browser.

I still long for a world where we got ASM.js and SIMD directly in JavaScript.

How about writing it properly in an efficient language that doesn't use a GC? (i.e. Rust or something equivalent)