9 ms·

require is way way faster in Ruby 2.0 typically bundle exec rails c will drop from 8 seconds to 4 just by upgrading the vm. optimising this is not an impossibl

by sams99 14y ago

require is way way faster in Ruby 2.0 typically bundle exec rails c will drop from 8 seconds to 4 just by upgrading the vm. optimising this is not an impossible problem its just going to take time, its far from a trivial one.

vidarh 14y ago
It is fairly trivial if you're willing to acknowledge the real problem: You can't pretend to not know about paths. You can make the current case faster by optimizing this and that, but it boils down to reducing the number of stat calls, and the ways to do that are: - Minimize the number of paths in the $LOAD_PATH. Ideally there should be one path there, but that might not be practical. - require_relative everything when you know where it is. As a bonus you get substantial less risk of breakage because of accidental filename clashes (yes, I've had filename clashes happen several times). Now, this isn't quick, because it'd mean making people used to require 'gem-name/file' and have gem/bundle ensure that the default load path contains a symlink to the real current include path for every gem, but this doesn't even need a single interpreter change. The problem here is not the Ruby implementations, but the gem ecosystem: This only becomes difficult if one wants the interpreter to automagically find files you've dropped all over the filesystem.
- judofyr 14y ago
  The biggest problem here is RubyGems which uses "load the specification for every gem you have installed"-approach. 300 gems installed = 300 files read at startup. See also https://github.com/judofyr/quickgem https://github.com/judofyr/quickgem for a monkey-patch that speeds startup time up to 4x.
  - vidarh 14y ago
    300 files is nothing. I just strace'd an app I'm playing with that does 145,000 stat calls on startup.... It's in the process of being rewritten to do require_relative whenever possible. As for the gems, it'll probably end up with a hack to "precompile" a list of absolute paths after installation...
- pmahoney 14y ago
  Another option is to build an index of the various parts of $LOAD_PATH. I monkeypatched (JRuby) to do this at runtime (that is, re-index every launch), and I saw a modest speed up in Rails boot time. If there were a standard way to build a semi-permanent index (updated by 'gem install', etc.), I'd expect the index to give even further gains. Of course, this is more invasive than your suggestions. https://gist.github.com/pmahoney/3996724 https://gist.github.com/pmahoney/3996724

by sams99 14y ago

vidarh 14y ago

It is fairly trivial if you're willing to acknowledge the real problem: You can't pretend to not know about paths. You can make the current case faster by optimizing this and that, but it boils down to reducing the number of stat calls, and the ways to do that are: - Minimize the number of paths in the $LOAD_PATH. Ideally there should be one path there, but that might not be practical. - require_relative everything when you know where it is. As a bonus you get substantial less risk of breakage because of accidental filename clashes (yes, I've had filename clashes happen several times). Now, this isn't quick, because it'd mean making people used to require 'gem-name/file' and have gem/bundle ensure that the default load path contains a symlink to the real current include path for every gem, but this doesn't even need a single interpreter change. The problem here is not the Ruby implementations, but the gem ecosystem: This only becomes difficult if one wants the interpreter to automagically find files you've dropped all over the filesystem.

judofyr 14y ago
The biggest problem here is RubyGems which uses "load the specification for every gem you have installed"-approach. 300 gems installed = 300 files read at startup. See also https://github.com/judofyr/quickgem https://github.com/judofyr/quickgem for a monkey-patch that speeds startup time up to 4x.
- vidarh 14y ago
  300 files is nothing. I just strace'd an app I'm playing with that does 145,000 stat calls on startup.... It's in the process of being rewritten to do require_relative whenever possible. As for the gems, it'll probably end up with a hack to "precompile" a list of absolute paths after installation...
pmahoney 14y ago
Another option is to build an index of the various parts of $LOAD_PATH. I monkeypatched (JRuby) to do this at runtime (that is, re-index every launch), and I saw a modest speed up in Rails boot time. If there were a standard way to build a semi-permanent index (updated by 'gem install', etc.), I'd expect the index to give even further gains. Of course, this is more invasive than your suggestions. https://gist.github.com/pmahoney/3996724 https://gist.github.com/pmahoney/3996724