Speed regression when using sass-embedded in webpack

[Clarkkkk]

Recently I tried to use sass-embedded in a private project with webpack's sass-loader and saw a speed regression (build time from 1min 12s to 1min 40s). I try to reproduce the issue in a simple example (with bootstrap), but sass-embedded is indeed faster in that example.

According to alexander's suggestion to find the reason of slower compilation, I enabled the profiler during compilation.

Here is the processed txt file: https://1drv.ms/t/s!AqaKW1-15JGra_rU4o09K44A04E. (It generates 12 files after compilation, and this is one that includes sass-embedded. If you need the others, I can provide them as well.)

Both sass-loader and sass-embedded are latest version.
Device: M1 Mac mini
OS: Mac OS 12.3.1
Node: 16.11.1

[ntkme]

• How many sass entrypoint files do you have?
• How many sass dependencies files do you have for each entrypoint?
• Are you using legacy API or new API?

One thing to note is that sass-embedded is generally faster to compile a single entrypoint that ends up as a single large css file (e.g. bootstrap) due to faster execution of Dart compared to JS. However, it can be a lot slower compiling lots of tiny files due to each entrypoint would spawn a new process for its compilation. sass/sass#3296 tracks the ability to re-use the process.

You can see this comment which demonstrates the performance difference of re-using the compiler process with the ruby-host.

Also, the JS implementation of google-protobuf is not very performant as it is currently written in pure JS, which contributes to some of the further slowness when compiling lots of small files. This has huge performance impact especially when you use legacy API instead of new API, that the emulated legacy API reads all files on the host side, and convert it to protobuf in order to pass content of each file (including all dependencies) via stdio to the compiler.

The last performance note is that for sass JS API the sync version is faster, but for sass-embedded the async version is faster.

[Clarkkkk]

There are over 1000 scss files and entrypoints in the project. And I am using legacy API. I tried modern API and it is still slower than the js version sass. It seems there is not much I can do but keep an eye on sass/sass#3296.

[ntkme]

Also, for the current dart-sass-embedded official release, macOS x64 build is a self-contained native executable, but arm64 is a runtime+snapshot combo, which has an even higher startup overhead. You can try compiling a native executable for macOS arm64. I think it will be a little bit faster but it's hard to tell how much improvement you will get without testing.

[nex3]

@ntkme is correct; the embedded host is currently expected to be somewhat slower for compilations involving many small files, at least until sass/sass#3296 is fixed.