[sass] Improve compilation speed using a different pow implementation#5674
[sass] Improve compilation speed using a different pow implementation#5674markov00 merged 6 commits intoelastic:mainfrom markov00:2022_03_01-improve_pow
Conversation
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5674/ |
|
Interesting! I had to write this a long, long time ago. As I remember, I needed this for ways to calculate luminance and respective contrast ratios. This among many other reasons are why I'm excited to move to a CSS-in-JS world and leave Sass behind. On a cursory check I'm seeing no changes in the contrast calculations so this looks OK at least from an output standpoint on the Sass. Here's the blog I wrote about doing all this in Sass, which felt pretty novel at the time. |
Thanks for sharing, I also saw that the I hope, SASS or not, we can soon switch to the new proposal for computing the contrast ratios called APCA that will be the default adopted in the WCAG 3 (currently in a draft state) |
|
🚀
|
|
Also an easy way to test that this still results in the same output values (or at least better if not similar since I've found sometimes the calculations are slightly off) is to run the Sass to JSON script and see the diffs. |
|
@cchaos I've just verified it right now checking the MD5 of the resulting files and they all coincide (except for the non minified version due to slight different indentation) but |
Thanks @thompsongl In fact I was going to ask what was is your preference in this case, adding the dependency or copying the files. Happy to change it.
|
|
What is an MD5? 😬 |
|
@thompsongl I've tried importing it via using |
Is a simple hash value computed from the file, it's used to compare if the content of two files are the same |
Just synced with Marco. The Sass file import will cause problems for consumers using targeted imports. |
|
Sounds great! |
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5674/ |
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5674/ |
thompsongl
left a comment
There was a problem hiding this comment.
Pushed one organization commit, but the rest looks great; thanks @markov00!
Confirmed that the compiled CSS does not change with the new function.
|
Preview documentation changes for this PR: https://eui.elastic.co/pr_5674/ |
|
I just want to say, this had an extraordinary impact on the Kibana bundling time... Is there a chance that we can make some sort of effort to maintain this improvement? |
|
The code is in the EUI repo so we can make any necessary changes. But I'm not sure what that maintenance looks like after we convert everything to CSS-in-JS and no longer use Sass. |
Summary
This PR reduces the SASS compilation times using a different math.pow implementation code.
I've noticed that compiling
@elastic/chartsSASS files (that imports some mixins and variables from EUI) takes a very long time.I've tried to debug the status of the SASS compilation and I've found that the time spent on the
powfunction available insrc/global_styling/functions/_math.scssis huge and slow down a lot the compilation.I tried to replace the
powoperation with the implementation coming from https://github.com/strarsis/sass-math-pow and the speed gain was significant to consider opening a draft/testing PR here.In particular I've tested this assumption both with
sassand withdart-sass(the native dart version, not the js port) to compile our sass styles with the following results:from:
to:
a 10x speedup
Locally I've tested the same compiling EUI and these are the results:
from:

to:

I'd like to run this PR to check the difference in a CI run (I've checked one of the latest PR and the compilation time was around 110seconds).UPDATE:In this PR the SCSS compilation took 22 seconds vs the ~120seconds in the current master
from (I've picked the one of the latest PR on the repo):
to:
Checklist