GemBench

Gem: "Put me in coach!" You: ❨╯°□°❩╯︵┻━┻

gem_bench is the super easy way to trim down app load times by keeping your worst players on the bench.

It is a fact of RubyGems that many of them do not need to be loaded by your app at boot time. It is a fact of Bundler that you don't know which ones need to be 'required' while staring at the Gemfile. It is a fact of Heroku that you only have 60 precious seconds to get your app loaded before ❨╯°□°❩╯︵┻━┻

This gem helps by telling you which gems don't need to be loaded during boot time.

You can even use it to evaluate your project's actual Gemfile for easy peasy boot time savings. (see Advanced Usage)

Installation

You may not need to add this gem to your project. You have three options, 1, 2 or BEST:

Option 1

Just install it, and require it in yourirb/console session when you want to use it. However, if you load your console with bundle exec then you only have access to gems in the gemfile, so either load without bundle exec or add it to the Gemfile.

$ gem install gem_bench

Option 2

If you decide to include it in your project: add this line to your Gemfile in the :development group.

gem 'gem_bench', :require => false, :group => :development

Option BEST

Or better yet follow the bundle group pattern in your Gemfile and setup a console group so it will only load in the console, and not the web app. With it loading only in the console session the require: false is completely optional. The gem is tiny, so won't impact console load time much. Requiring it will allow checking your Gemfile without needing to first require 'gem_bench'.

gem 'gem_bench', :group => :console

And then execute:

$ bundle

Usage

Fire up an irb session or a rails console and then:

>> require 'gem_bench'
=> true
>> team = GemBench.check({verbose: true}) # verbose: true => print output, verbose: false => just returns a GemBench::Team object you can inspect.

Here is an example irb session where I have installed only gem_bench, rails, and bundler. For the first run I don't require any gems besides gem_bench.

For the second run I require 'rails' as well, and now I can see which rails dependencies are required at boot time. I am in a project with a Gemfile, (gem_bench) but it doesn't depend on rails.

See that? Only 3 of the 14 gems rails loads need to be required when your app boots, technically! However, in order to prevent loading them we would have to make them primary dependencies, listed in the Gemfile, which isn't really the best idea. Moving on... If you run the check against a real app's Gemfile it will find numerous primary dependencies that don't need to be required at app boot. See Advanced Usage :)

In a random directory, in an irb session, where there is no Gemfile in sight it will give a lot more information:

Advanced Usage

In order to also see list gems may not be required at boot time you need to:

  1. Make sure you are in the root of a project with a Gemfile
  2. Make sure the gem is actually a dependency in the Gemfile

So here's a fat Gemfile weighing in at 265 gem dependencies. We'll use it for this example:

gem_bench found 45 gems which are listed as primary dependencies in my Gemfile which I can add require: false to.

How much faster will my app boot loading 45 fewer gems? A bit.

Note: Some of the gems in the list above should have been excluded. They are now excluded as of gem_bench version 0.0.4.

Future

This gem determines which gems need to be loaded at Rails' boot time by looking for Railties and Engines. A future verison will also look for initializers, because gems which have code that runs (e.g. configuration) in an initializer also need to be loaded at boot time.

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Added some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Make sure to add tests for it. This is important so I don't break it in a future version unintentionally.
  6. Create new Pull Request

Versioning

This library aims to adhere to Semantic Versioning 2.0.0. Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, a new version should be immediately released that restores compatibility. Breaking changes to the public API will only be introduced with new major versions.

As a result of this policy, you can (and should) specify a dependency on this gem using the Pessimistic Version Constraint with two digits of precision.

For example:

spec.add_dependency 'gem_bench', '~> 0.0'