command line latency with berkshelf 6.2.0

[lamont-granquist]

going from 6.1.1:

% berks --version
6.1.1
% time berks install
Resolving cookbook dependencies...
Using compat_resource (12.19.0)
Using yum-epel (2.1.2)
berks install  1.27s user 0.24s system 98% cpu 1.532 total

to 6.2.0:

% berks --version
6.2.0
% time berks install
Resolving cookbook dependencies...
Using compat_resource (12.19.0)
Using yum-epel (2.1.2)
berks install  4.28s user 0.63s system 99% cpu 4.950 total

this is a side-effect of moving to making berkshelf depend on chef itself rather than pulling in ridley and the rest of the berkshelf gems, and will not be treated as a regression or a bug.

the way to fix this is to bundle in order to reduce gem loading time:

% berks --version
6.2.0
% time bundle exec berks install
Resolving cookbook dependencies...
Using yum-epel (2.1.2)
Using compat_resource (12.19.0)
bundle exec berks install  0.75s user 0.15s system 97% cpu 0.912 total

or to use the appbundled binstubs in chef-dk -- and this is precisely the issue they were designed to solve.

long-term the plan is to convert berkshelf to using more of core chef itself, and to remove its deps on ridley/buff-*/varia_model, etc.

then the plan is to break up the chef gem itself to make it more manageable (extracting out more gems like chef-config, like the http client, the object model, etc)

once that is done then the loading time for un-bundled berkshelf will improve again.

ETA though is likely "on the order of a year or more".

[lamont-granquist]

On ruby-2.5.1 with berkshelf 7.0 this is looking more comparable (all the old berkshelf support libraries are removed):

Running entirely unbundled:

• 6.1.1: 1.08s
• 6.3.2: 1.42s
• 7.0.0: 1.13s

Closing this.

Still the recommended approach is to either use the binstubs out of /opt/chefdk/bin/berks or to bundle exec against a limited set of gems.