8 ms·
Bootsnap: Optimizing Ruby App Boot Time
- dismantlethesun 9y agoI'm kinda shocked that Ruby boot times can be up to 25 seconds for a monolithic app. A Python project I work on has 279,124 lines of code and boots up in 2.5 seconds. Without downloading it, all I can find is Discourse had 60,000 lines of code 3 years ago [1]. Assuming as an extreme estimate they tripled their code size in 3 years, we have 180,000 LOC taking 6 seconds to boot up according to the article. Is this normal for Ruby? Is the author using a spinning disk drive rather than an SSD? [1] https://github.com/bleonard/rails_stats https://github.com/bleonard/rails_stats
- jitl 9y agoIn this case, you need to analyze not only the applications source code, but also the size and quantity of its dependencies, which inflate Ruby's LOAD_PATH, which as discussed makes `require` slow. The issues raised here are typical for a large Ruby application with many gem dependencies. I think it's safe to assume the author using reasonable SSDs on a Macbook Pro, given that the iseq cache targets only macOS.
- choward 9y agoDoes your Python app load all at once or lazily load as you hit different parts of the app?
- dismantlethesun 9y agoIt loads all at once, part of the bootstrap does a check of all the mvc modules and templates. I'm not 100 percent sure if third party modules for background tasks get loaded and the same time but they aren't part of my line of code count.
- burke 9y agoFWIW, the machine that generated all of those times: * MacOS Sierra * 2.6 GHz Intel Core i7 * 16GB 2133 MHz LPDDR3 * 500GB SSD, whatever Apple ships.
- burke 9y agoThe largest culprit for slow ruby boot times is an O(n) number of syscalls over the LOAD_PATH each time `require` is called, so the number of syscalls is essentially O(n*2) to the number of gems. The load-path-caching feature of bootsnap (cf. bootscale) fixes this, and accounts for a reduction from 25 to ~9.5 seconds. The iseq/yaml caching only accounts for the last ~3.5 seconds.
- lathiat 9y agoAaron Patterson did a really great talk detailing the process called "Code Is Required". He's a really great presenter both humour wise and manages to often explain relatively technical things very understandably. Highly recommend watching this (and his other stuff) you can watch it here: https://www.youtube.com/watch?v=_bDRR_zfmSk https://www.youtube.com/watch?v=_bDRR_zfmSk
- EvilTrout 9y agoDiscourse co-founder here. I'm not sure about those stats you posted from 3 years ago since they aren't using the same `rake stats` numbers that are built in to Rails. Discourse's Rails app is currently 63k SLOC not including tests. On my relatively fast computer booting takes 4s without bootsnap and 2.5s with it, which is a nice quality of life improvement.
- deleted 9y ago[deleted]
- est 9y agoIf you try zc.buildout, your python code start time will drop significantly. It will insert gazillion sys.path.
- burke 9y agoI'm the primary author, can answer questions if you have any.
- kellysutton 9y agoHi burke! This definitely looks interesting. Boot times for majestic monoliths is a pain that I've experienced many times. How does the fit in with zeus and/or spring? How similar is this to bootscale? (https://github.com/byroot/bootscale https://github.com/byroot/bootscale) Or rails-dev-boost? (https://github.com/thedarkone/rails-dev-boost https://github.com/thedarkone/rails-dev-boost)
- burke 9y ago> How does the fit in with zeus and/or spring? Two orthogonal optimizations: It definitely plays nice with spring, speeding up the pre-fork rather a lot, and the post-fork a little bit. I can't think of any reason it wouldn't also work with zeus, but I haven't tried it. > How similar is this to bootscale? The load-path-caching features are a minor evolution of bootscale. The major difference is that the caching is a little more aggressive in order to be confident enough to return definitive negative results when it thinks a feature is non-present on the load path. I remember using rails-dev-boost years ago, but I can't really remember what it does (EDIT: Should be a similar story to Spring -- complementary optimizations)
- kellysutton 9y agoCool. Thanks!
- wolco 9y agoCurious when did shopify go with Ruby/rails. If I remember when the company was initially started they were looking for php developers. Was the orginal stack built in Ruby/rails?
- burke 9y agoNope, we've been Rails since before Rails was even public. I'm sure we've hired a PHP developer here and there over the years, but our core platform has always been Ruby.
- chrisseaton 9y agoIn the implementation of Ruby that I work on, TruffleRuby, we've been exploring lazy parsing, where the parser will find a method but not fully parse it until the method is called for the first time. I wonder if there's any other modifications you could make to the VM itself to improve startup time.
- tomstuart 9y agoHow difficult is lazy parsing for Ruby? How much parsing do you need to do just to find where the method body ends?
- chrisseaton 9y agoYou basically have to do all the parsing, but you can delay creating the actual AST and other data structures like byte code, which for us is the really expensive bit.
- tomstuart 9y agoMakes sense, thanks. So you end up redoing most of this (parsing) work later when you want the AST, but a) you might not have to redo it at all if the method's never actually called, and b) it's not the expensive bit anyway?
- chrisseaton 9y agoYes. But if you have source code that you know you will likely be requiring such as the standard library, you can do the initial parsing while compiling the Ruby VM, so you don't end up doing the parse twice at runtime. Long term what we hope to do is to provide a build of the Ruby VM that includes the version of Rails you are using pre-parsed. And then longer term we'd like to actually fully parse and initialise Rails (run the top level of the files which are loaded) during compilation, and freeze the heap and store it in the Ruby VM executable. When you run this special Ruby/Rails VM the Rails code is simply mmapped into your address space with all objects initialised and ready to go. Obviously it'll require some tweaking to delay doing this like starting the web server so that doesn't get run during compile time.
- dobs 9y agoGave this a quick shot on my own monolithic app and it cut startup time almost in half. Impressive considering how easy it was to configure! Startup time was one reason we started migrating away from Rails in a previous workplace, between frustrating startup time in development and test and occasional quirkiness of zeus and spring. Bootsnap would have been a godsend.
- burke 9y agoI've tossed around the idea of writing zeus again now that I actually understand the language I wrote it in. Spring is much simpler, but because of the manner in which it's loaded, it isn't capable of detecting certain types of file change, which reduces developer confidence in it. Zeus is capable of detecting any sort of invalidating file change, but is pretty buggy (or at least was historically -- the Stripe guys improved it a lot after I stopped working on it).
- ischi 9y agoStill fairly buggy,some terminal issues should be fixed now but reloading has race conditions still.
- iagooar 9y ago-
- burke 9y agoHonestly, it works well for us. DHH may have been a little rosier than necessary: there are some downsides, to be sure, but we can mitigate them to a large extent (e.g.: TFA), and we get a lot of benefit out of the architecture. It is definitely a net positive for us. YMMV, of course.
- noir_lord 9y ago> In 2017 there is really no reason to defend a monolithic architecture. I wonder if in 2019 I'll be seeing "In 2019 there is really no reason to define a micro-services architecture". The pendulum it keeps on swinging.
- jitl 9y agoThis is awesome, and I'd love to use it for the command-line dev tools that I write. Unfortunately this gem requires Ruby 2.3+, but macOS built-in Ruby, which is the Ruby we target, is only 2.0.0. Does anyone know of a good solution for prebuilt, relocatable Rubies on macOS that I could easily bundle with my tool? I'm reluctant to use Homebrew or another package manager like rbenv, where I'd have to implement a non-trivial bootstrap process. Phusion's travelling-ruby project would be perfect, but it's unmaintained. I just want my CLI to boot in 0.05s without needing to change languages. Love Ruby, but getting decent perf takes a bit of effort.
- jacobevelyn 9y agoAs a fellow Ruby CLI developer, I feel your pain exactly. I've been planning on exploring Traveling Ruby[^1] for exactly this reason (as well as the fact that telling users they need to `sudo gem install` something is non-ideal) but hadn't yet gotten around to it. Out of curiosity, what's your tool(s)? [^1]: https://github.com/JacobEvelyn/friends/issues/160 https://github.com/JacobEvelyn/friends/issues/160
- jitl 9y agoI write an internal developer tool at Airbnb that is conceptually similar to Vagrant. We get around the 'sudo gem' problem by distributing our tool as a git repo, then bootstrapping a vendored install of Bundler to manage our own little gem path using /usr/bin/ruby. We take care to remove most ruby-related env vars during init so we're safe from whatever crazy RBENV or RVM shenanigans are happening on the system. This setup works fine, but we don't get recent language perf improvements since we use system Ruby.
- burke 9y agoHeh. I write an internal developer tool at Shopify that is (somewhat) conceptually similar to vagrant. (https://twitter.com/burkelibbey/status/858013844626649092 https://twitter.com/burkelibbey/status/858013844626649092) Like you, we distribute it as a git repo. We don't use bootsnap with it, but we have a few strategies that give us reasonable times: $ time ./bin/dev help up >/dev/null 0.07s user 0.03s system 98% cpu 0.102 total * We vendor every dependency (and try really hard to avoid them in the first place -- we have 5, only one of which is >5 source files), and prevent loading rubygems. Rubygems takes a long time to load. Our shebang is `/usr/bin/ruby --disable-gems`. * Autoload everything. Our toplevel lib/dev.rb file is a whole-namespace autoload registry. Only a few other constants are defined there. Everything is loaded just by cascading through autoloads. * Defer stdlib requires: We load most stdlib features within the method body from which they're used. Several stdlib features take a surprisingly long time to load.
- JohnBooty 9y agoWow! This is potentially a real gain for us. We have a big in-house, monolithic Rails app. My initial experiment was encouraging. Boot time in development mode went from ~23sec to ~16sec, and I only enabled it for the main engine that comprises about 85% of our codebase so the real gains might be larger. Looking forward to seeing what it can do in production mode - our boot times there are horrendous and it's a big deal for things like cron jobs. Thank you to all those who worked on this.
- misterbowfinger 9y agoAre there plans to support JRuby?
- burke 9y agoNo. I'm not opposed to it, but we don't use it at Shopify and I doubt the RubyVM::InstructionSequence API is compatible. Bootscale should work, and the load-path-caching feature of bootsnap should work too, if you can get the gem to install.
- ausjke 9y agoConsidering PHP7, Java8/Kotlin, Go, C++17, Python3, Javascript/ES6 etc these days, how will Rudy be doing in the long run? any reason for new comers to pick up Ruby instead of the mentioned list? I just started using PHP myself.
- quotha 9y ago5.times { print "Odelay!" }
- zapt02 9y agoI think Ruby is essentially dead in the waters. It just has no unique selling point. Python is better at small scripts, machine learning and mathematical application. PHP7 has much better tooling for HTTP, the largest CMS systems and doesn't have any boot time to speak of. JS & Node is the new kid on the block with tons of great libraries being written for it. Why would you start to learn Ruby today?
- Something1234 9y agoUsing jekyll and maintaining existing stacks.
- spo81rty 9y agoAnd .NET Core/C#
- deedubaya 9y agoAvoiding a flame war, it depends on what your goals are. From a language standpoint: Ruby emphasizes developer happiness at the expense of some things, like performance/concurrency for example. From a career standpoint: There is a lot of ruby in the world today. There will be lots of applications to maintain as the years go on, which is +1 from a career perspective. Lots of people will also continue to write new ruby software, because it's effective and easy to be productive in. All the languages you mentioned + ruby are all good languages to learn for various reasons. All have their weaknesses and strengths. None of them are an effective hammer for every nail you'll encounter.
- Cerium 9y agoThanks for releasing this, I gave it a try. Starting benchmark time: 13.05 seconds. With load_path_cache: 10.01 seconds Sadly, with compile_cache on I'm getting an error. /vendor/bundle/ruby/2.3.0/gems/bootsnap-0.2.14/lib/bootsnap/compile_cache/iseq.rb:30:in `fetch': No space left on device (Errno::ENOSPC) Any ideas on what causes this?
- burke 9y agoYep, you're probably using linux. The cache backend for compiled artifacts is filesystem extended attributes, which have a maximum size of 64MB on darwin, but as little as 4kB on some linux configurations (if they're even enabled, which they often are not). Practically speaking, the compilation caching features are not supported on linux. Eventually we'll change the cache backend or add a different one that does work on linux.
- Cerium 9y agoYes. I am using Linux. Thanks for the quick response.
- deleted 9y ago[deleted]
- omarforgotpwd 9y agoMight have missed something, but why not just merge these changes into Rails?
- yxhuvud 9y agoFor starters, because it only works on mac.