On 7 April 2015 at 10:43, Robert Collins wrote:
>> $ time openstack -h
>>
>> real0m2.491s
>> user0m2.378s
>> sys 0m0.111s
>
>
> pbr should be snappy - taking 100ms to get the version is wrong.
I've now tested this.
With an egg-info present in a git tree:
python -m timeit -n 1 -r 1 -
On 9 April 2015 at 01:12, Flavio Percoco wrote:
> On 08/04/15 08:59 -0400, Doug Hellmann wrote:
>> 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 as
On 9 April 2015 at 00:59, Doug Hellmann wrote:
>> > Another data point on how slow our libraries/CLIs can be:
>> >
>> > $ time openstack -h
>> >
>> > real0m2.491s
>> > user0m2.378s
>> > sys 0m0.111s
>>
>>
>> pbr should be snappy - taking 100ms to get the version is wrong.
>
> I have
On Wed, Apr 8, 2015 at 7:59 AM, 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 wrote:
> > >
> > >
> > > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews >
> > > wrote:
> > >>
> > >>
> > >> On Mon, Apr 6, 2015 at
On 04/08/2015 11:25 AM, Dolph Mathews wrote:
> On Wed, Apr 8, 2015 at 9:33 AM, Ryan Brown 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
On Wed, Apr 8, 2015 at 9:33 AM, Ryan Brown 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 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 wrote:
>>> >
>>> >
>>> > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
>>>
>>> > 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 wrote:
>
>
> On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
> wrote:
>>
>>
>> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic wrote:
>>>
>>> J
Excerpts from Robert Collins's message of 2015-04-07 10:43:30 +1200:
> On 7 April 2015 at 05:11, Joe Gordon wrote:
> >
> >
> > On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
> > wrote:
> >>
> >>
> >> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic wrote:
> >>>
> >>> Jay,
> >>>
> >>>
> Not fa
> On 7/4/2015, at 0:43, Robert Collins wrote:
>
> On 7 April 2015 at 05:11, Joe Gordon wrote:
>>
>>
>> On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
>> wrote:
>>>
>>>
>>> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic wrote:
Jay,
> Not far, IMHO. 100ms differen
On 7 April 2015 at 05:11, Joe Gordon wrote:
>
>
> On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
> wrote:
>>
>>
>> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic wrote:
>>>
>>> Jay,
>>>
>>>
Not far, IMHO. 100ms difference in startup time isn't something we
should spend much time optimi
On Mon, Apr 6, 2015 at 8:39 AM, Dolph Mathews
wrote:
>
> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic 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
By the way, this review in question has merged and will be part of the
(soon) next release of keystone client.
--Morgan
On Monday, April 6, 2015, Dolph Mathews wrote:
>
> On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic > wrote:
>
>> Jay,
>>
>>
>> Not far, IMHO. 100ms difference in startup time
On Mon, Apr 6, 2015 at 10:26 AM, Boris Pavlovic 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 ar
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
On 04/06/2015 07:02 AM, Brant Knudson wrote:
On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic mailto:bo...@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.gi
Excerpts from Brant Knudson's message of 2015-04-06 09:02:55 -0500:
> On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic wrote:
>
> > Brant,
> >
> > I run profimp with and without patch
> > https://review.openstack.org/#/c/164066/:
> > And it really works well:
> >
> > before 170ms:
> > http://boris-
On Sun, Apr 5, 2015 at 5:41 PM, Boris Pavlovic 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/a
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
Best regards,
Boris Pavlovic
On Fri, Apr 3, 2015 at 2:44 AM,
On 04/02/2015 06:22 PM, Brant Knudson wrote:
> On Thu, Apr 2, 2015 at 4:52 PM, Boris Pavlovic wrote:
>
>> Hi stackers,
>>
>> Recently, I started working on speeding up Rally cli.
>>
>> What I understand immediately is that I don't understand why it takes
>> 700-800ms
>> to just run "rally versio
On Thu, Apr 2, 2015 at 4:52 PM, Boris Pavlovic wrote:
> Hi stackers,
>
> Recently, I started working on speeding up Rally cli.
>
> What I understand immediately is that I don't understand why it takes
> 700-800ms
> to just run "rally version" command and it is impossible hard task to find
> what
Hi stackers,
Recently, I started working on speeding up Rally cli.
What I understand immediately is that I don't understand why it takes
700-800ms
to just run "rally version" command and it is impossible hard task to find
what takes so much time just by reading the code.
I started playing with
22 matches
Mail list logo