How do gems affect Rails application performance?

Question

I'm new to Rails, and this may be a dumb question, but I wonder how the number of gems affects Rails application performance? Does it get slower the more stones you add? Are all gems called up for each request?

I ask this question because, for example, in Django you import every necessary class / method / library into every .py file that calls it. In Rails you do not do this, everything is “autoload”, but I wonder what the cost of such an “autoload” is?

Does this mean that all gems are called up for each request?

Answer 1

Autoload is just a method to replace "import every necessary class / method / library" with "if you put files in a specific place, we can find them."

The basic algorithm is something like "if you use a class or module and it is not found, before we tell you that we cannot find it, find it on one of these paths."

Startup is orthogonal to the search for gems, but rather the search for application code. In other words, your gems are downloaded and required from your Gemfile once when you launch the application, but the startup mechanism does not work on gems, but on your application code.

So, to answer the first part of your question: loading gem is not directly related to startup. The inclusion of new gems in your application can make the application launch a little slower, since the library is found and analyzed, but they are loaded for the whole time after launch; this will not affect the performance of your request.

It's good to know that RubyGems are part of Ruby, and startup is part of Rails: Rails is a framework written on top of Ruby, just like Django is a framework written on top of Python, but Ruby and Rails are very different. Gems are part of Ruby, and startup is part of Rails.

Startup is designed to speed up development; instead of restarting the server every time you make changes, if you follow the directory layout convention, your files (and only the files in your application) will be reloaded for each request. This is good because you can just leave your server running during development.

It is worth noting that this is only true in development mode. In production mode, he will find the file if it will be absent only once and remember it in the requests, in order to save you the overhead of searching for the file system for each request. In fact, if you use Rails 3.2 or higher, it becomes smart enough even in development mode to reload the file only if it has changed since the last request, which makes things even faster during development.

You do not need to use autoload, btw: you can manually require files you need, just like you spoke with Python. This is the standard way for Ruby to do things. It will cost you to autoload this entire file since your constants are never "found": this is good because it will increase the performance of your application, but bad because you will have to restart the application every time you change your code.

tl; dr: don't worry about startup performance. This will help you in development mode due to application performance and will work in production mode due to development speed.

Answer 2

The number of gems will affect the performance of your Rails application in the following ways:

• When starting the application / loading the environment, all stones must be loaded. This download obviously takes longer if there are more gems. You will especially notice this during development, as you will load your environment (hopefully) many times (for example, every time you run unit test).
• Extra (downloaded) code also requires more space, so your application will consume more memory if you use more gems.

Both points are pretty thin and you won't notice the difference between loading 5 or 10 gems. But as soon as you reach numbers like 20 or 50 stones, you will begin to notice ...