[openstack-dev] [all][oslo][clients] Let's speed up start of OpenStack libs and clients by optimizing imports with profimp

Dolph Mathews dolph.mathews at gmail.com
Wed Apr 8 16:25:37 UTC 2015


On Wed, Apr 8, 2015 at 9:33 AM, Ryan Brown <rybrown at redhat.com> wrote:

> On 04/08/2015 09:12 AM, Flavio Percoco wrote:
> > On 08/04/15 08:59 -0400, Doug Hellmann wrote:
> >> Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:
> >>> On 7 April 2015 at 05:11, Joe Gordon <joe.gordon0 at gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
> >>> <dolph.mathews at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >>
> >>> >> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic
> >>> <boris at pavlovic.me> wrote:
> >>> >>>
> >>> >>> Jay,
> >>> >>>
> >>> >>>
> >>> >>>> Not far, IMHO. 100ms difference in startup time isn't something we
> >>> >>>> should spend much time optimizing. There's bigger fish to fry.
> >>> >>>
> >>> >>>
> >>> >>> I agree that priority of this task shouldn't be critical or even
> >>> high,
> >>> >>> and that there are other places that can be improved in OpenStack.
> >>> >>>
> >>> >>> In other hand this one is as well big source of UX issues that we
> >>> have in
> >>> >>> OpenStack..
> >>> >>>
> >>> >>> For example:
> >>> >>>
> >>> >>> 1) You would like to run some command X times where X is pretty big
> >>> >>> (admins likes to do this via bash loops). If you can execute all
> >>> of them for
> >>> >>> 1 and not 10 minutes you will get happier end user.
> >>> >>
> >>> >>
> >>> >> +1 I'm fully in support of this effort. Shaving 100ms off the
> >>> startup time
> >>> >> of a frequently used library means that you'll save that 100ms
> >>> over and
> >>> >> over, adding up to a huge win.
> >>> >>
> >>> >
> >>> >
> >>> > Another data point on how slow our libraries/CLIs can be:
> >>> >
> >>> > $ time openstack -h
> >>> > <snip>
> >>> > real    0m2.491s
> >>> > user    0m2.378s
> >>> > sys     0m0.111s
> >>>
> >>>
> >>> pbr should be snappy - taking 100ms to get the version is wrong.
> >>
> >> I have always considered pbr a packaging/installation time tool, and not
> >> something that would be used at runtime. Why are we using pbr to get the
> >> version of an installed package, instead of asking pkg_resources?
> >
> > Just wanted to +1 the above.
> >
> > I've also considered pbr a packaging/install tool. Furthermore, I
> > believe having it as a runtime requirement makes packagers life more
> > complicated because that means pbr will obviously need to be added as
> > a runtime requirement for that package.
> >
>
> RDO actually patches out calls to pbr to avoid the runtime requirement,
> FWIW.
>

How does RDO handle --version arguments?


>
> --
> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150408/cd6cc276/attachment.html>


More information about the OpenStack-dev mailing list