sassc-ruby: sassc is very slow to compile and install
When doing a bundle install for a new Rails 6 app, I noticed most of the time is spent compiling sassc (libsass really).
This takes easily up to 2 minutes on Linux, which feels really slow for one gem. A bit of a Nokogiri-like experience if you see what I mean. Speaking of Nokogiri, they now have a prerelease gem installing in just 1 second, maybe we can use a similar approach?
$ ruby -v
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux]
$ time gem install sassc
Building native extensions. This could take a while...
Successfully installed sassc-2.2.1
1 gem installed
89.75s user 5.43s system 99% cpu 1:36.12 total
I’m not sure what’s the best way to address this but here are some ideas:
- Use the Makefile of libsass to build libsass as a shared library, and just link the C extension to it (as it used to be).
- Use make parallelism automatically, e.g., by setting MAKEFLAGS
- Distribute a binary gem on Linux and macOS. This requires having an easy workaround for non-glibc (e.g., alpine) to install from source, or not depending on on glibc (by linking the libc statically?).
- Changes in libsass so it compiles faster, such as #132.
- I thought the
-fltomight slow things down but actually it seems to speed up compilation withg++ 8.3.1!time gem install sassc -- --disable-ltotakes113.71s user 6.01s system 99% cpu 2:00.70 total. Disabling all flags gives:time gem install sassc -- --disable-lto --disable-march-tune-native --disable-static-stdlib=>109.80s user 5.63s system 99% cpu 1:56.12 total.
Use the Makefile of libsass to build libsass as a shared library
That already builds quite a bit faster:
$ time BUILD=shared make
...
70.53s user 3.94s system 99% cpu 1:14.93 total
I would think the main gain there is that’s compiled with -O2:
g++ -Wall -O2 -DLIBSASS_VERSION="3.6.1" -std=c++11 -I /home/eregon/code/libsass/include -fPIC -c -o src/remove_placeholders.o src/remove_placeholders.cpp
instead of (with gem install sassc):
g++ -I. -I/home/eregon/.rubies/ruby-2.6.5/include/ruby-2.6.0/x86_64-linux -I/home/eregon/.rubies/ruby-2.6.5/include/ruby-2.6.0/ruby/backward -I/home/eregon/.rubies/ruby-2.6.5/include/ruby-2.6.0 -I. -I./libsass/include -fPIC -O3 -ggdb3 -std=c++11 -march=native -mtune=native -flto -DLIBSASS_VERSION="3.6.1" -o remove_placeholders.o -c ./libsass/src/remove_placeholders.cpp
We can also parallelize it (I have 4 cores + 4 hyperthreads, i7-7700HQ CPU @ 2.80GHz):
$ time BUILD=shared MAKEFLAGS=-j4 make
81.15s user 4.51s system 387% cpu 22.132 total
That’s a reasonable install time!
Using just the MAKEFLAGS approach with gem install is not quite enough:
time MAKEFLAGS=-j4 gem install sassc
Building native extensions. This could take a while...
Successfully installed sassc-2.2.1
1 gem installed
95.47s user 5.63s system 180% cpu 55.870 total
Relates to #132
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 121
- Comments: 43 (11 by maintainers)
Commits related to this issue
- pin sassc-rails to 2.1.0 See https://github.com/sass/sassc-ruby/issues/189#issuecomment-731424768 — committed to apolopena/gp-react-on-rails-base by apolopena 3 years ago
- gem: pin sassc to 2.1 ideally we'd remove sassc as we make no use of it but in the meantime: https://github.com/sass/sassc-ruby/issues/189#issuecomment-926950953 — committed to unboxed/bops by freesteph 3 years ago
- gem: pin sassc to 2.1 ideally we'd remove sassc as we make no use of it but in the meantime: https://github.com/sass/sassc-ruby/issues/189#issuecomment-926950953 — committed to unboxed/bops by freesteph 3 years ago
- gem: pin sassc to 2.1 ideally we'd remove sassc as we make no use of it but in the meantime: https://github.com/sass/sassc-ruby/issues/189#issuecomment-926950953 — committed to unboxed/bops by freesteph 3 years ago
- gem: pin sassc to 2.1 ideally we'd remove sassc as we make no use of it but in the meantime: https://github.com/sass/sassc-ruby/issues/189#issuecomment-926950953 — committed to unboxed/bops by freesteph 3 years ago
- gem: pin sassc to 2.1 ideally we'd remove sassc as we make no use of it but in the meantime: https://github.com/sass/sassc-ruby/issues/189#issuecomment-926950953 — committed to unboxed/bops by freesteph 3 years ago
- gem: pin sassc to 2.1 ideally we'd remove sassc as we make no use of it but in the meantime: https://github.com/sass/sassc-ruby/issues/189#issuecomment-926950953 — committed to unboxed/bops by freesteph 3 years ago
- gem: pin sassc to 2.1 ideally we'd remove sassc as we make no use of it but in the meantime: https://github.com/sass/sassc-ruby/issues/189#issuecomment-926950953 — committed to unboxed/bops by freesteph 3 years ago
- Prevent slow compile times of sassc gem Recent updates of Alpine / Sassc has resulted in very slow compile time for this version. Temporarily revert to 2.1.0 until this issue has been fixed upstream.... — committed to ministryofjustice/network-access-control-admin by emileswarts 3 years ago
- Prevent slow compile times of sassc gem Recent updates of Alpine / Sassc has resulted in very slow compile time for this version. Temporarily revert to 2.1.0 until this issue has been fixed upstream.... — committed to ministryofjustice/network-access-control-admin by emileswarts 3 years ago
- Prevent slow compile times of sassc gem (#245) Recent updates of Alpine / Sassc has resulted in very slow compile time for this version. Temporarily revert to 2.1.0 until this issue has been fixed ... — committed to ministryofjustice/network-access-control-admin by emileswarts 3 years ago
Adding more data about the impact of this: I came to realise that Jekyll depends on
saascindirectly (viajekyll-sass-converter, which is a hard dependency).This makes Jekyll (fairly popular) quite slow to deploy on platforms like Netlify (see https://community.netlify.com/t/ruby-gems-cache-seems-to-be-ineffective/14821 for an example, the install times is above 3 minutes. Caching is another problem ^_^).
I’ve opened an issue at https://github.com/jekyll/jekyll/issues/8184 to evaluate if
sasscbe made a soft dependency, but still wanted to provide this feedback: the impact of this is probably quite large on a number of projects.Not sure what can be done and how I could help either yet, so for now just providing this data.
Are there plans to address this, specifically shipping pre-compiled binaries for Debian or other popular distros?
Up to version 2.1.0, sassc shipped precompiled Linux binaries, but as of 2.2.0, the only precompiled versions are for mingw32.
The problem, apparently (#141) was that on Alpine Linux (common in Docker images) rubygems would download the “Linux” version, precompiled with
libc(not available on Alpine, which usesmuslinstead to keep the image size down).Other gems (Nokogiri is one I’ve noticed in particular) seem to get around this somehow, though, using the precompiled version on Debian and RedHat and other
glibcsystems, while compiling from source on Alpine. I’m not sure why or how — as a mostly macOS and Docker/Alpine user, I only just noticed the existence of precompiled gems a few weeks ago when I noticed thatbundle installin a Debian-based container was going much faster than my previous Alpine-based builds. 🙂 But it might be worth looking into.In the meantime, a workaround might be to pin
sassc-rubyto version 2.1.0.This has always taken a lot of time to install, however, for some reason, lately this started taking over 10 minutes to install in Travis, which makes it cancel the build completely. Although I can work around this, it’s odd that this should really take over 10 minutes to install. It also wasn’t a one-off thing, travis quit when attempting to install sassc 10+ times in a row now.
Are there any more clever work arounds than increasing Travis’ timeout limit?
Turns out that it’s only bloody slow when it is installing with “native extensions”. 🤔
Got the same issue on netlify, took 5-10 minutes to install sassc 2.4.0.
If anyone finds this helpful, here is where it actually takes 2 minutes (I installed
ffiseparately because it’s a dependency and for comparison w/time):This is where it took ~2 minutes.
same case here, it takes more than 9 minutes to install causing the cancelation of the bundle install 😕
For an older app, we were spending ~8 mins on sassc in our Docker installs. It was painful because any Gemfile change invalidated the Docker layer for the
bundle installSince this gem feels unlikely to get a new release, we took the lowest lift approach here and are doing a
RUN gem install sassc:2.4.0before ourRUN bundle installline.This means the sassc install is cached in its own layer and the bundle install uses the sassc gem on disk. While the flag changes suggested here save real time, having the install cached means future builds spend zero seconds on sassc.
I wrote about this in more detail here.
Thanks this is a really great hint! ❤️
FWIW, here are numbers from today on my current Linux desktop on CRuby 3.1.3:
So setting
MAKEFLAGSto the CPU count helps a lot there.@Pablushka @dancingmonkey @aamejia @h0jeZvgoxFepBQ2C
*** ATTENTION ***
LibSass is deprecated. SASSC-RUBY depends on LibSass. Ruby on Rails has moved away from using this gem. You should not be using this gem.
*** WHAT TO DO ***
Most people have experienced this issue during an upgrade. Most gems and apps that previously required or depended on this library are now using a new library. Consider updating any gems or apps that depend on this library to a newer version and it will likely no longer require this gem.
Updating your various required gems or Rails version is often enough to fix this issue as the new versions shouldn’t be requiring or referencing this gem.
Sometimes just commenting out the “sassc-ruby” or “sassc” gem requirements in your Gemfile may be enough, although this may cause other errors to then trace and resolve.
Dart Sass is a new implementation of Sass if you want to look into it. https://github.com/rails/dartsass-rails
Note: This advice is provided without any warranties or represenations of any kind.
I think the damage this issue is doing to the adoption of RoR and Ruby and contributing to the downfall of these tools is underestimated. Unfortunately I don’t have enough knowledge to collaborate on a solution. It’s pitiful…
For those dealing with this issue in their Rails app(s), I was able to replace this gem with https://github.com/rails/cssbundling-rails by following this helpful article: https://dev.to/kolide/how-to-migrate-a-rails-6-app-from-sass-rails-to-cssbundling-rails-4l41
I’m not sure if this is any use, but the wkhtmltopdf-binary gem includes precompiled binaries for a numbers of platforms, and will just pick the most appropriate one at runtime.
This of course trades disk space for cpu cycles, but it could be a nice option to offer? I know I’d take it.
For me it took longer, but it worked perfectly.
This is still an ongoing issue on new installs for me as well.
It’s definitely not a guarantee enough, see my comment over here.
From experience maintaining a
mini_racerfork over a couple of years just for the purpose of adding more platforms, it’s immeasurably better to just consider-linuxto be equal to-linux-glibcand-linux-musl(or-linux-uclibc) to be entirely distinct.We have another binary gem, called
libsqreen. That C++ one we control entirely and build with, link against, and package together with LLVM C++ libs. It results in a hefty package but that’s the only other solution we found.IIRC the reason is that on some Alpine systems, Ruby ends up being set up to pick the non-binary gems only, and so never reaches to the
-linuxbinary one. Indeed,alpine:3.12ruby hasGem.platformsbe only[:ruby], which is not the case forruby:2.7-alpine, returning["ruby", #<Gem::Platform:0x000055fc7e52a730 @cpu="x86_64", @os="linux", @version="musl" @cpu="x86_64", @os="linux", @version="musl">]. Note how there even the gem platform is wrong and@versionisnilonruby:2.6-alpineand below, being["ruby", #<Gem::Platform:0x0000557454d74330 @cpu="x86_64", @os="linux", @version=nil @cpu="x86_64", @os="linux", @version=nil>](which IIRC has more to do with the bundled rubygems version that ruby’s).Right. It seems for Nokogiri they just dynamically link to glibc (the default) and apparently in that case it seems binary compatible with musl (I checked with
lddand require-ing+using Nokogiri in both environments). I guess that’s not a guarantee though and might not always work?