0

I am trying out ruby-prof and ran it against a somewhat self-contained module. The core of the module is 3 classes, with maybe 3 other helper classes being used. So there shouldn't be a huge amount of overhead with tons of requires and incluces. Is this normal in a big(gish) app with a fair number of gems installed?

 18.06      7.67     1.99     0.00     7.66     1366  Kernel#require
  5.80      1.21     0.64     0.00     0.83    18704  Array#map
  5.73     10.21     0.63     0.00    10.09    38133  Array#each
  5.17      1.13     0.57     0.00     0.56    21796  Array#include?
  4.40      0.49     0.49     0.00     0.00   345434  Symbol#to_s
  3.78      0.42     0.42     0.00     0.00   446478  String#==
Jeremy Smith
  • 14,727
  • 19
  • 67
  • 114
  • A fair number of gems? Can you elaborate? Seems like that would likely account for the require time. – Ryanmt Jun 13 '11 at 22:29

2 Answers2

1

From ruby-prof's documentation:

To profile a Rails application it is vital to run it using production like settings (cache classes, cache view lookups, etc.). Otherwise, Rail’s dependency loading code will overwhelm any time spent in the application itself (our tests show that Rails dependency loading causes a roughly 6x slowdown).

Are you running this using production settings? If you aren't using cached data and instead have to read the files/classes from disk every time, I can understand why you are seeing your system spend so much time in Kernel#require.

bta
  • 43,959
  • 6
  • 69
  • 99
0

I ran ruby-prof on a similar case, according to your description, except that mine only requires two gems, which I wouldn't consider qualifies as 'a fair number'. That being said, I still spent 10% of my 7 second run time with the Kernel#gem_original_require class.

I imagine that what you are seeing is pretty typical, as it seems to be comparable to my case.

Ryanmt
  • 3,215
  • 3
  • 22
  • 23