tophf

This change doesn't seem to improve anything because `defer` keeps the scripts in practically the same position they were previously, i.e. just before DOMContentLoaded. The only negligible difference is now...

Deoptimization is triggered by various patterns (some links: [Deoptimization in V8](https://docs.google.com/presentation/d/1Z6oCocRASCfTqGq1GCo1jbULDGS-w-nzxkbVF7Up0u0), [Optimization-killers](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers)). In your tests, `compress` invocations supposedly use the same parameter signature/types so the actual problem is within the...

Ah, indeed, no deopt on any of the functions if I test in devtools manually via copypaste, a primitive 100-rep loop, and console.time. The difference is negligible just the same....

> can you show me what the faster Map and Set code looks like? https://gist.github.com/tophf/e8962e43efe35233212cf04d8d7cd317 2x speedup compared to the nonminified original version as tested on compressToUTF16/decompressFromUTF16 in modern versions...

@JobLeonard, it'd be interesting to combine your approach with Map/Set as discussed in #47 (I'm using a locally modified version that's ~2 times faster overall). Also, this is definitely worth...

JavaScript doesn't use zero-terminated strings so it's not clear why this concept should be applied here unless it'll provide some benefits.

"Easier" should be quantified. Is that loop so overcomplicated currently that it obstructs further development? Slows down execution? I find this zero-terminated string idea really weird in JavaScript and probably...

@wintifrosch, isn't it something that can be (and should be) solved via existing specialized solutions? Like WebWorker, for example.

>do you need an unsafe variant? No, we would use workers.

Yes, I'm using a worker, and I use an async Proxy wrapper to invoke it. BTW, uBlock Origin apparently implemented LZString-based compression in WASM module.