3 ms·

I'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 s

I'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 ago
In 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 ago
Does your Python app load all at once or lazily load as you hit different parts of the app?
- dismantlethesun 9y ago
  It 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 ago
FWIW, 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 ago
The 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 ago
  Aaron 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 ago
Discourse 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 ago
If you try zc.buildout, your python code start time will drop significantly. It will insert gazillion sys.path.

jitl 9y ago

In 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 ago

Does your Python app load all at once or lazily load as you hit different parts of the app?

dismantlethesun 9y ago
It 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 ago

FWIW, 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 ago

The 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 ago
Aaron 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 ago

Discourse 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 ago

If you try zc.buildout, your python code start time will drop significantly. It will insert gazillion sys.path.