Redmine

Since Rails 5.2, new applications generated with rails new have included bootsnap in their Gemfile by default. Redmine does not currently use it, but adding it cuts the boot time by about half.

Bootsnap caches expensive operations involved in loading Ruby and YAML files and resolving require calls against $LOAD_PATH. The cache lives under tmp/cache and can be reused on subsequent boots.

The first patch is a preparation step: it updates config/boot.rb, which is still based on the Rails 3.2 template Redmine adopted in r9528. Rails has changed it twice since: 8572fcd9f (rails/rails#16046) dropped the if File.exist? guard around bundler/setup, so that a missing Gemfile fails at boot instead of silently booting without Bundler, and 7d6a8320e rewrote the Gemfile path as File.expand_path('../Gemfile', __dir__), that is, relative to the directory instead of to __FILE__. Redmine always ships a Gemfile and the new expression points at the same file, so a normal installation boots as
before.

The second patch enables bootsnap: it adds the gem to the Gemfile and requires bootsnap/setup in config/boot.rb, as generated by rails new:

require 'bundler/setup' # Set up gems listed in the Gemfile.
require 'bootsnap/setup' # Speed up boot time by caching expensive operations.

The third patch documents the cache in a new section of doc/INSTALL.

Time from starting bin/rails runner -e production 'nil' until it exits, on macOS 15 (arm64), Ruby 4.0.6, SQLite3, no plugins, no Gemfile.local. trunk and patched were run alternately, 5 times each, with the bootsnap cache already built:

A few things to be aware of. The cache under tmp/cache/bootsnap grows to about 30 MB; bootsnap never removes it, but rake tmp:cache:clear from the upgrade procedure does. The first boot after a deployment builds the cache and is not faster. On slow storage such as NFS the cache can cost more than it saves; the new doc/INSTALL section covers moving it with BOOTSNAP_CACHE_DIR or turning bootsnap off with DISABLE_BOOTSNAP=1`.