Does DartSASS 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 DartSASS caching works, so opening this ticket to clarify things.

I’ve also posted same ticket at LibSASS.

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. However, there is no documentation covering this functionality. Isn’t it deployed yet? Could you please shed light on how to use this functionality?

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

[nex3]

Dart Sass doesn't cache anything to disk. As far as I've been able to tell, the main compilation bottleneck happens during stylesheet evaluation. Parsing is very fast, so I don't know that storing serialized parse trees would provide any tangible benefit.

Dart Sass does cache parse trees in memory, though. #326 enabled that across compilations when multiple stylesheets are compiled at once using the command-line interface. It's meant to be transparent to the user, so there's no public-facing API for it.

If you're looking for the best performance possible under Dart Sass, your best bet is to use the stand-alone executable which uses the very fast Dart VM.

[sergeymorkovkin]

Natalie, so precompiled partials cache makes sense, right? Do you think it's possible to somehow tap into SASS internal context for every partial (vars, mixins and function)? Or rendered CSS is all we have through public API?

[nex3]

Natalie, so precompiled partials cache makes sense, right?

I'm not 100% sure what you mean by this question.

Do you think it's possible to somehow tap into SASS internal context for every partial (vars, mixins and function)?

Not currently. At some point in the future, once the module system has been released, we may expose an API (likely Dart, possibly also JavaScript) that provides the ability to examine and invoke functions, mixins, and variables defined in a given module.

[sergeymorkovkin]

I'm not 100% sure what you mean by this question.

I mean there is a room for improvement. My idea is to cache precompiled partials within a bundle, in memory. So, during first pass we could populate cache, which would make things faster on following compilations.

I'll try to make a POC for this.

[pomarec]

I thik this issue of sass-loader might be relevant to people like me who are trying to speed up their development time and landed in this conversation.

My situation : I work on a VueJS project where we import a (rather big) sass file in every vue views. Each time we change a view's <style> content, the sass file get re-compiled.
One of the solution stands in webpack-contrib/sass-loader#774, an other one could be disk caching evaluated dart-sass modules ?

Edit: Caching evaluated modules seems hazardous as it's very well explained there

[griswold]

@pomarec I was wondering if you found a solution to your problem or a workaround. I'm working on a project with what I believe to be the same problem: every scss file in the project @uses a common module which pulls in many other files via @forward. I think this is the source of our slow build times. Wondering if I'm using an anti-pattern or if there's some other way that folks are handling this. Thanks in advance!

[pomarec]

@griswold Not really i'm afraid. I just dumped sass.

[nex3]

@griswold sass/sass#2745 is probably the best solution for that pattern—it would provide loaders with a way of telling the Sass compiler that a bunch of separate compilations are happening at the "same time", so that Sass can cache information including loaded modules in memory across those compilations. We haven't had time to dive into it yet, but we could always use help if you're interested in pitching in!

[griswold]

Thanks @nex3! Really appreciate you taking the time to point me in the right direction. Will take a look to see if I understand this well enough to make an impact, would love to help if I can.