Does LibSASS have a precompiled partials cache?

[sergeymorkovkin]

This is not a bug, but rather a potential feature request. I haven’t found any information highlighting how LibSass caching works, so opening this ticket to clarify things.

I’ve also posted same ticket at DartSASS.

In Browserify we have caching mechanism, which stores pre-compiled partials. This notably shortens repeated processing times by eliminating FS/IO, parsing, transformation and sourcemaps generation.

In SASS, however, it’s more complex, since precompiled partials should also contain transpile-time context such as variables, mixins and functions.

Do you think it’s possible to cache precompiled partials? If no, can we at least cache pre-parsed partials?

I’ve done NodeSASS vs DartSASS performance comparison. Here is what I’ve found:

• NodeSASS and DartSASS performance behavior is identical;
• NodeSASS is 10-12% faster than DartSASS;
• Enabling Fibers for DartSASS doesn’t make any difference (OS X 10.14.4, Node 11.10.1);

I’ve seen this feature merged into DartSASS, stating it’ll allow to cache imports across compilations. Wondering if it's deployed and can be used.

In general, LibSASS and DartSASS are both fast, but still there is a room for improvement. What do you think?

[xzyfer]

This is not something we have plans to do at this time.

[sergeymorkovkin]

Could you please share your thoughts about this? In my opinion, we can at least cache partials on a per-bundle basis (by using custom imports and render callback), eliminating disk IO and redundant bundle recompilations. Is this the edge of what's possible at the moment or is there some other improvement I'm missing?

[mgreter]

I don't think this is feasible or that it would bring much performance improvement. We could write the parsed AST tree to disk and load that instead of the actual scss file in case it hasn't changed. But in comparison to the expand and eval stage, the parsing does not really take that much time. E.g. a huge scss file with just nesting (very simple to expand) still only takes up to 25% of the total time. Given the overhead of adding the changed check and parsing the "read-optimized" ast node tree from disk, I would guess that a maximum 10% improvement could be achieved by adding some caching here.

One could think about caching already fully evaluated trees, but that is not easy given to dynamic nature of the sass language, e.g. @extend alone makes it nearly impossible, since it can extend selectors throughout the whole document. It might be possible to derive some logic to make partially evaluated ast trees a thing, and that could bring some substantial gain across reoccurring compiles, but definitively not something very easy to get right.

I will close this as it is very low priority, but added it to the wish-lish ticket instead.

[sergeymorkovkin]

Marcel, thank you for detailed explanation. Very instructive and helpful!