I have been observing that openstack client is slow to start, a handful of second for a simple command.
I ran the pyflame profiler on a simple command (keystone user creation) and observed that a very large fraction of the time is spent by the plugin initialization code (openstackclient/common/clientmanager.py:get_plugin_modules) in call to pkg_resource.iter_entry_points (see attached profiling traces), which itself is spending most of its time in parsing requirements (pkg_resources/__init__.py:parse_requirements).
I don't actually have an idea of how to fix this, but it seems to me that in the case where openstack client is used to run one command of one plugin, initializing all plugins may perhaps be avoided.
Note that I looked at this after observing that a devstack stack.sh on my typical environments takes a significant amount of time in the openstack client command:
=========================
DevStack Component Timing
=========================
Total runtime 896
run_process 10
test_with_retry 3
apt-get-update 2
pip_install 202
osc 186 <=====================
wait_for_service 16
dbsync 23
apt-get 113
=========================
I'm thinking that saving a large fraction of something that takes a significant fraction of stack.sh, itself taking a large fraction of a typical devstack job, may end up bringing a measurable improvement to the overall CPU load of the openstack CI.
I've investigated deeper and perhaps found a place in setuptools that could lead to a significant improvement to iter_entry_point performance (the hotpoint to which the flamegraph above is pointing at).
See https:/
Applying the change proposed in this issue, on a devstack with only 5 osc extensions installed, results from "openstack user list" total runtime improving from 2.6s to 1.7s.