[openstack-dev] [openstackclient] osc slowness

Doug Hellmann doug at doughellmann.com
Tue Apr 14 13:18:32 UTC 2015

Excerpts from Dean Troyer's message of 2015-04-13 18:41:37 -0500:
> On Mon, Apr 13, 2015 at 5:20 PM, Doug Hellmann <doug at doughellmann.com>
> wrote:
> > Excerpts from Sean Dague's message of 2015-04-13 07:15:57 -0400:
> > I *believe* the time is scanning the plugins. It doesn't actually
> > load them, but it has to look through all of the entry point
> > registries to find what commands are available. I originally built
> > cliff (the framework under OSC) this way because I thought we would
> > put the commands in separate repositories.
> >
> FWIW, as things grow commands for projects outside layers 1 & some of 2 are
> in external repos.  The some of time here is due to doing all imports up
> front rather than as required; I've proposed
> https://review.openstack.org/173098 as the first step to fix this.

Cleaning up import behavior is another good optimization. Maybe the
extra imports account for more of the startup time than the entry point

> > Since we aren't doing that for the vast majority of them, we can
> > change the implementation of cliff to support hard-coded commands
> > more easily, and to have it only scan the entry points for commands
> > that aren't in that hard-coded list. We would need to load them all
> > to generate help output and the tab-completion instructions, but I
> > think it's OK to take a bit of a penalty in those cases.
> >
> If we do the above the entry point scan is maybe two orders of magnitude
> faster without the forced imports.
> I am also working on at least one deferred import inside cliff itself, cmd2
> is pokey...

I've had "remove use of cmd2" on my list for cliff for a while now, too.
I don't even remember, at this point, what led me to start using it over
the cmd modules in the stdlib, so figuring that out is the first step to
dropping it entirely.


> dt

More information about the OpenStack-dev mailing list