RFC: Improvements to a compiler to make it fast

[layershifter]

Griffel features a compiler (available as a Webpack loader, Vite plugin, etc.) that executes Ahead-of-Time (AOT) compilation to enhance runtime performance and shift workload to the build phase. The compiler also enables CSS extraction, offering significant performance benefits for applications.

However, we got multiple reports indicate that the compiler's speed is suboptimal. This project seeks to enhance the compiler's performance.

Preview

[github-actions]

📊 Bundle size report

✅ No changes found

[spmonahan]

Just a thought, feel free to disregard entirely 😃

You could adopt Rust as the primary language and target WASM. By doing this you avoid the need to build binaries for all platforms and open the door for running the compiler in the browser (though this seems like a neat thing rather than something immediately useful). This potentially comes at the cost of some raw performance but I would expect is to be significantly faster than the status quo.

Rust has good tooling for WASM: https://rustwasm.github.io/docs/wasm-bindgen/

[layershifter]

That's what @Anber proposed yesterday 🐱 It's what we will need to check once we will have something working.

The problem with WASM that we faced before with @ling1726 - the cost of moving strings between JS & WASM worlds. Longer strings => worse results, as the following happens:

for (let i = index; i < index + size; ++i)
  s += String.fromCharCode(buffer[i]);

https://stackoverflow.com/a/41372484/6488546

AFAIK there is nothing better yet than messing up with Uint8Arrays that was proven to be extremely slow when we re-implemented @emotion/hash with WASM and managed to get faster than JS only with a custom memory allocator.

[spmonahan]

Not sure if this helps, but the wasm-bindgen str docs state:

If you don't want to perform this copy, and would rather work with handles to JavaScript string values, use the js_sys::JsString type.

Which implies you can avoid the copy and still work with the string on the WASM/Rust side of the house

https://rustwasm.github.io/wasm-bindgen/api/js_sys/struct.JsString.html

[ling1726]

In order for strings to exist in the wasm shared memory (which is essentially numbers) serialization with shared buffers still need to happen. Once wasm-bindgen compiles the output will output something like this

function passStringToWasm0(arg, malloc, realloc) {

    if (typeof(arg) !== 'string') throw new Error(`expected a string argument, found ${typeof(arg)}`);

    if (realloc === undefined) {
        const buf = cachedTextEncoder.encode(arg);
        const ptr = malloc(buf.length, 1) >>> 0;
        getUint8ArrayMemory0().subarray(ptr, ptr + buf.length).set(buf);
        WASM_VECTOR_LEN = buf.length;
        return ptr;
    }

    let len = arg.length;
    let ptr = malloc(len, 1) >>> 0;

    const mem = getUint8ArrayMemory0();

    let offset = 0;

    for (; offset < len; offset++) {
        const code = arg.charCodeAt(offset);
        if (code > 0x7F) break;
        mem[ptr + offset] = code;
    }
   // etc....

If wasm-bindgen has fs access - it might be possible to only do serialization into a buffer once, and write the output from the wasm side... but that text encoding will still need to happen to make sure the string exists in shared mem in the first place. I believe 'copy' inferred here means that a separate string exists in wasm memory 😢

[ling1726]

code snippets in diagrams seem to be broken for me

[ling1726]

Suggested change

	function require(moduleId) {
	function __require_wd40_module(moduleId) {

Have I understood this require correctly?

[ling1726]

this example uses a simple function transform for spacing. If this function became more complicated to use imported constants do I understand correctly that it could become:

__wd40_module('theme.ts', function (module, exports, require) {
  exports.spacing = value => {
    value + require('/contants.ts').PX;
  };
});

if the export used other functions in the module, would the tree shaking also include those functions in the wd40 module?

[ling1726]

it would certainly be interesting to cache the output of the input files and their dep trees to enable incremental builds on style files for large codebases.

However, if fully using Rust will be so blazing fast, it might not be necessary 🤔

[ling1726]

Might want to make it clear that non-performant syntaxes like export * will be supported eventually or if that will be indefinitely not supported?

[ling1726]

what is the motivation for an option that uses a bundler's resolver?