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

Ben Nemec openstack at nemebean.com
Wed Apr 8 17:31:31 UTC 2015


On 04/08/2015 11:25 AM, Dolph Mathews wrote:
> 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?

The version is hard-coded as part of the patch process.  Not useful in
non-package based environments where the version isn't static,
unfortunately.




More information about the OpenStack-dev mailing list