v1.5.0

This release is a huge one for the Wasm backend. tl;dr, memory usage should be dramatically reduced with a small improvement in CPU performance. This means that now, for any application with relatively complex regular expressions, there is expected to be no tradeoff for using this library.

There are two notable changes in this release, using shared memory among compiled regex's, and updating to wazero's new optimizing compiler.

Previously, WebAssembly only supported single-threaded execution within an instance of the Wasm module. To allow some concurrency within applications using go-re2's Wasm backend, we instantiated the Wasm module once per regex. This means that an individual regex still cannot be accessed concurrently, but multiple ones can. This in practice results in decent concurrency. However, the memory overhead of a fully instantiated Wasm module is relatively high - imagine all the error messages possible for invalid regular expressions, and them being copied into every single instantiated module. That is just one example of significant waste with this model.

With WebAssembly threads support for shared memory, we can now instead instantiate the module once and rely on atomic operations within the Wasm to allow safe access to memory in the context of concurrent access. This removes wasted copies of static resources and minimizes the overhead of the Wasm backend. In some cases, we see several hundred of megabytes improvement in overhead.

Unfortunately, switching to shared memory meant losing some optimizations such as buffer reuse that assumed non-concurrent access to memory. The overall performance impact from this seemed to be about 10-15% - it would probably still be worth it for the memory savings, but it's never fun to introduce performance regressions. Luckily, our friends at wazero launched a completely new optimizing compiler backend with a large improvement in performance. For go-re2, we saw around 20% improvement from switching to the new compiler. This means that overall, with this release, performance should be mostly the same with some possible single-digit gains, but with the memory usage tradeoff of the Wasm backend eliminated. The optimizing compiler was a huge effort and special thanks to @mathetake for driving that through to completion.