3 minutes to precompile about bootstrap-sass

[thomas-mcdonald]

All on a mid-2010 Macbook Pro (2.4GHz Core 2 Duo)

Rails 3.1 app (with a reasonable set of additional stylesheets):

tom:qa tom$ time rake assets:precompile
/Users/tom/.rvm/rubies/ruby-1.9.3-p0/bin/ruby /Users/tom/.rvm/gems/ruby-1.9.3-p0/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets
/Users/tom/.rvm/rubies/ruby-1.9.3-p0/bin/ruby /Users/tom/.rvm/gems/ruby-1.9.3-p0/bin/rake assets:precompile:nondigest RAILS_ENV=production RAILS_GROUPS=assets

real    1m3.207s
user    0m34.134s
sys 0m3.595s

Almost fresh Rails 3.2 app:

tom:librarian tom$ time rake assets:precompile
/Users/tom/.rvm/rubies/ruby-1.9.3-p0/bin/ruby /Users/tom/.rvm/gems/ruby-1.9.3-p0/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets

real    0m39.350s
user    0m21.538s
sys 0m1.657s

I can't really reproduce the 3+ minutes you're seeing.

[dnagir]

40 seconds (Rails 3.2) is still relatively long. In moderate sized app assets are compiled within ~15secs or so if I don't use bootstrap-sass.

But for me the new Rails 3.2 boostrap-sass compiles very fast.
So there must be something specific to my config (https://gist.github.com/1832369).

Here's full output just in case:

> time RAILS_ENV=production bundle exec rake assets:precompile
/Users/dnagir/.rvm/rubies/ruby-1.9.3-p0/bin/ruby /Users/dnagir/.rvm/gems/ruby-1.9.3-p0/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets

real    3m0.787s
user    2m46.590s
sys 0m5.156s

There might be an issue with something else, not bootstrap-sass.

[dnagir]

Ohh,

I think I have nailed it down. In the config I have config.autoload_paths += %W(#{config.root}/lib).
Removing this line from application.rb makes assets compile within 11 seconds.

(There are no any assets in lib at all).

I suspect that's a sass/rails issue, not exactly sure.

[dnagir]

Actually, that's not right. The compilation just quits with an error which I looked at as success. So, no it's not the autoload_paths thing :(

The compilation time is 17s when I remove app/assets/stylesheets/frameworks.css.sass file.

The content of it is just:

@import "bootstrap"
@import "bootstrap-responsive"

So there's really something to do with bootstrap-sass.

[thepixelmonk]

getting a similar issue, cpu shoots to 100% and just seems to stall when I include a file identical to frameworks.css.sass as described above. If I remove it and include twitter bootstrap normally, everything's fine.

[lukesaunders]

I also see slow precompile times for my sass files which import bootstrap. But what seems odd is that in development mode where it just recompiles when source files change it seems to be able to regenerate those files in just one or two seconds. Why the difference?

[assembler]

+1
It takes around 2 minutes to precompile on Heroku

[jrissler]

+2 takes at least 2-3 minutes

[masterkain]

5 minutes here in production

[ouranos]

3-4 minutes for me using ruby 1.9.3-p125 & Rails 3.2.1.

[alexeymorozov]

5 minutes for me :(

[utkarshkukreti]

5 minutes for me on Heroku with responsive, 2 minutes without responsive.

[daddyz]

2 minutes on rails 3.2.2 and ruby 1.9.3-p125
also I tried to run it in development environment and it took about 10 seconds

[artiom]

+1

[rainkinz]

+1

[benzheren]

+1

[thomas-mcdonald]

Hey guys, sorry it's taken a while for me to sit down and get back to you all on this one, I've had the allure of much more pleasant tasks than profiling calling me.

From browsing through previous issues, it looks like this issue will most likely lie within Sprockets, specifically the way it handles finding files. However, I can't be sure until I get chance to sit down with ruby-prof, it's particularly odd considering how fast reloading files is in development as opposed to production.

With Bootstrap 2.0.2 coming soon I intend to spend most of tomorrow going through the issues and getting everything in order with the Gem framework, before looking at the style changes. Hopefully I'll make some progress somewhere.

[dnagir]

@thomas-mcdonald, now worries. Thanks for getting on the issue.
Not sure I can trace it down too much further, but if you need any additional info please let us know.

ASIDE: Do you know what the changes are in the 2.0.2?

[davidjrice]

@thomas-mcdonald I've looked into this. I can specifically trace this down to importing the bootstrap-responsive styles.

@import "bootstrap-responsive";

Without this one line. My assets compile in 50 seconds with, it takes 4 minutes 30 seconds.

If I do a trace of the Ruby process running rake assets:precompile I can see a massive amount of nesting. It looks very much like sprockets is having a hard time processing this file.

[dnagir]

I don't think it's only the responsive.
50 secs is still way too long. Removing imports decreases time step by step.

For example, importing and compiling compass only takes ~15 seconds.

So definitely there must be something to do with the bootstrap-sass.

On 11/03/2012, at 11:08, David [email protected] wrote:

@thomas-mcdonald I've looked into this. I can specifically trace this down to importing the bootstrap-responsive styles.

@import "bootstrap-responsive";

Without this one line. My assets compile in 50 seconds with, it takes 4 minutes 30 seconds.

---

Reply to this email directly or view it on GitHub:
#62 (comment)

[davidjrice]

Considering that internally rails runs

rake assets:precompile:primary then rake assets:precompile:nondigest

With both tasks loading the assets environment. That's about 25 seconds each. Which I would like to be faster for sure however any improvement is going to be less beneficial than the immediate 3 minutes 40 seconds saving!

Let me see if stripping bootstrap requires down further gives any statistically significant improvement in our app.

[davidjrice]

Okay. Stripping out our @import 'bootstrap' and replacing it with a more granular set of imports that we actually need. As in _boostrap.scss same with requiring separate javascript modules in application.js. This reduces our total time by about 5 to 10 seconds.

Also noticed we could save some time by removing highcharts.js from our precompilation of application.css and statically referencing the library only on pages required. Saves another 5 seconds or so.

[davidjrice]

I've also put together a patch for rails that will speed up compilation for you by not bothering with the nondigest variants of your assets. Cutting our rake asset:precompile time significantly.

rails/rails#5379

[masterkain]

@davidjrice "save some time by removing highcharts.js from our precompilation of application.css and statically referencing the library only on pages required"

what?

[davidjrice]

@masterkain I was purely sharing other tips for cutting down asset precompilation. Obviously, the less stuff you have to compile the better.

The only issue here is boostrap-responsive takes an inordinate amount of time to compile.

[thomas-mcdonald]

So I created a new Rails 3.2.1 application, added RubyProf either side of internal_precompile and did two runs:

rake assets:precompile:primary
rake assets:precompile

assets:precompile:primary runs by default in development environment since I didn't change the environment using RAILS_ENV. assets:precompile invokes assets:precompile:all with this command:

 /Users/tom/.rvm/rubies/ruby-1.9.3-p0/bin/ruby /Users/tom/.rvm/gems/ruby-1.9.3-p0/bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUPS=assets

which in turn invokes assets:precompile:primary

My profiling runaround has led me to this piece of lovely code here:

def normalize_indentation(str)
  pre = str.split("\n").inject(str[/^[ \t]*/].split("")) do |pre, line|
    line[/^[ \t]*/].split("").zip(pre).inject([]) do |arr, (a, b)|
      break arr if a != b
      arr + [a]
    end
  end.join
  str.gsub(/^#{pre}/, '')
end

in which it would appear almost 100 seconds are spent in production, compared to < 1 in development. Naturally, this has left me wondering why, and I'm struggling to answer that.

[masterkain]

No idea, git blaming the file reveals that normalize_indentation was introduced initially to support comments.
Specifically it trims tabs before comment block:

"                           " # pre
                           /* IE6-7 */ # str

Also the pre variable is shadowed.

[iRonin]

I've just installed your gem and can say that SCSS precompile takes 8365ms-17128ms.
JS compilation is fast.

[masterkain]

summoning @nex3 ; maybe he has some observations..

[alexslade]

I noticed that removing the comments at the top of backbone-responsive solves this.
(Literally, remove the first few lines of comments, that's it)

I can only guess, but perhaps the asset pipeline is evaluating these comments or something?

[masterkain]

On EC2: command finished in 941875ms

[tonycoco]

@heeton In my fork of this, I took precompile time from 8 minutes down to 1 minute by removing those comments. We should look into why this is happening. SASS seems to be goofing the comment blocks up.

#92

[thomas-mcdonald]

37563aa, branch 2.0.2, give it a whirl.

[assembler]

works for me on Heroku. it now compiles in under a minute (and it took around 7 minutes before)

[tonycoco]

Yeah, this works great again.

[thomas-mcdonald]

Right, I'm going to close this then. Cheers for all the help.