Open Stack

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



>
>> 2) Bash completion - should be online.
>> For example, it takes about 600-700ms to run Rally, so we need to have
>> hardcoded bash completion scripts, because otherwise it is too slow and not
>> consumable.
>>
>> There are other use cases where starting speed is crucial but IMHO
>> authors of libs should help to make projects faster and users happier,
>> especially when it is quite simple task.
>>
>>
>>
>>> p.s. Boris, please don't hate me :)
>>
>>
>> I will ;)
>>
>>
>> Best regards,
>> Boris Pavlovic
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 6, 2015 at 5:54 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>>
>>> On 04/06/2015 07:02 AM, Brant Knudson wrote:
>>>
>>>> On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic <boris at pavlovic.me
>>>> <mailto:boris at pavlovic.me>> wrote:
>>>>
>>>>     Brant,
>>>>
>>>>     I run profimp with and without patch
>>>>     https://review.openstack.org/#/c/164066/:
>>>>     And it really works well:
>>>>
>>>>     before 170ms:
>>>>     http://boris-42.github.io/keystone/before.html
>>>>
>>>>     after 76ms:
>>>>     http://boris-42.github.io/keystone/after.html
>>>>
>>>> Looks like now the issue is that keystoneclient imports pbr.version so
>>>> that it can get pbr to generate the __version__ value. Maybe pbr could
>>>> be more efficient about the work it does on import, or we could figure
>>>> out a different / lazy way to generate the version string.
>>>> http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/
>>>> keystoneclient/__init__.py#n35
>>>>
>>>> How far do we need to go with this?
>>>>
>>>
>>> Not far, IMHO. 100ms difference in startup time isn't something we
>>> should spend much time optimizing. There's bigger fish to fry.
>>>
>>> Best,
>>> -jay
>>>
>>> p.s. Boris, please don't hate me :)
>>>
>>>
>>> ____________________________________________________________
>>> ______________
>>> 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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20150406/c915b19d/attachment.html>