-
Notifications
You must be signed in to change notification settings - Fork 33
Improve build slowness #169
Comments
In case this is helpful: jekyll/jekyll#1140 (comment) |
Made an issue for jekyll_pages_api as well: 18F/jekyll_pages_api#20 |
Are these raw benches or raw + parboiled benches? We have incremental regeneration so I would be interested in seeing what it's like after the raw build (on 3.0) but if that does not speed things up then we do have a problem that needs to be solved. |
I'm sure I didn't do a very thorough job with the benchmarks, as I'm not much of a Rubyist. If you've a preferred methodology documented somewhere, I can study up and take another shot. Anecdotally, it seemed like rebuilds were still on the order of 5-6s on my Yosemite machine, even with 3.0.0.pre.beta1; @shawnbot, running Mavericks, was getting O(30s) using 2.5.3. FWIW, we're also considering changing the architecture of the application in a way that may mitigate the problem (though that's not the only reason for the architectural change). |
this may or may not help, but I cloned my jekyll repo and started setting it up to use with Grunt. I didn't quite get there, but when I went back to trying to serve with Jekyll it was taking 1m+ for every save. Maybe the added files caused this? I switched back to the previous version and Jekyll serve is working fine again. |
Per yesterday's Documentation Working Group discussion, build times for the Hub appear to be creeping up. This makes Javascript development especially painful.
Using the
ruby-prof
gem via the following command reaffirmed common knowledge that Liquid accounts for most of the time:$ bundle exec ruby-prof --printer=call_stack --file=stack.out /usr/local/var/rbenv/versions/2.2.0/bin/jekyll -- build
Cloning the Jekyll repo and building a 3.0.0.pre.beta1 gem from the
master
branch didn't appear to impact the time very much.Some relevant links:
Possible approaches:
cc: @shawnbot @msecret @afeld @gboone
The text was updated successfully, but these errors were encountered: