RFC: startup time - again

[Russel Winder]

On Tue, 2008-09-09 at 13:01 +0300, Alexander Belchenko wrote:

> I disagree: human reaction is about 200-300 ms. So 500 ms is too much.
> Especially comparing to hg speed.

Certainly it is the case that human reaction time is 200--300ms but what
has that got to do with this situation?  Others have mentioned getting
things down to 0.1s to be deemed to be instantaneous, again more or less
true, but why is this an issue -- what I am driving at here is that
numbers like this should not be discussed in absolute terms and out of
context.

If all commands are to return "instantaneously" then clearly all should
be < 0.1s.  However, there is an issue of perception here, not just the
biomechanics of the human body.

On Tue, 2008-09-09 at 21:25 +0900, David Cournapeau wrote:

> I don't understand why bzr rocks is not a very useful metric: on my
> workstation, it takes 0.3 s for bzr rocks, to do nothing. This seems
to
> be the core issue for short time commands: what bzr rocks loads is a
> subset of what is needed by 'normal' bzr commands, right ? If bzr
rocks
> was say 0.05 seconds instead (on my workstation, a doing nothing
python
> script is 0.02s), all the other commands would also be faster, no ?

"bzr rocks" is a very useful metric for instantaneous since it is clear
that all it does is return a string, i.e. it is a variant of "Hello
World" -- it can be implemented:

	print "It sure does!"

So, a quick test:

        |> time bzr rocks
        It sure does!
        
        real	0m0.520s
        user	0m0.300s
        sys	0m0.096s
        |> time bzr rocks
        It sure does!
        
        real	0m0.660s
        user	0m0.420s
        sys	0m0.176s
        |> time python -c "print 'It sure does\!'"
        It sure does\!
        
        real	0m0.017s
        user	0m0.012s
        sys	0m0.004s
        |> time python -c "print 'It sure does\!'"
        It sure does\!
        
        real	0m0.018s
        user	0m0.020s
        sys	0m0.004s
        |> 

so here "bzr rocks" certainly fails, not specifically because it takes
>0.1s but because the user percieves that it is a "do nothing" command
and hence should be instantaneous and hence should take <0.1s.

Now a command such as "bzr missing" has effectively two outcomes, some
form of success, i.e. a report of the relative status of two branches,
or some form of failure.  So for example on a real branch:

        |> time bzr missing
        Branches are up to date.
        
        real	0m4.313s
        user	0m0.412s
        sys	0m0.128s
        |> time bzr missing
        Branches are up to date.
        
        real	0m1.980s
        user	0m0.496s
        sys	0m0.192s
        |> time bzr missing
        Branches are up to date.
        
        real	0m1.927s
        user	0m0.480s
        sys	0m0.152s
        |> 

Now a 2s response here may be acceptable since the user knows that some
work has to be done, so perceptually expects there to be a delay.  What
is irritating is the 4s which is just too long, especially when the same
command issued immediately afterwards takes half that time.  This
difference in performance is the real problem.

Then consider doing this in the wrong directory:

        |> time bzr missing
        bzr: ERROR: Not a branch: "/home/users/russel/".
        
        real	0m0.555s
        user	0m0.400s
        sys	0m0.100s
        |> time bzr missing
        bzr: ERROR: Not a branch: "/home/users/russel/".
        
        real	0m1.416s
        user	0m0.424s
        sys	0m0.116s
        |> time bzr missing
        bzr: ERROR: Not a branch: "/home/users/russel/".
        
        real	0m0.567s
        user	0m0.356s
        sys	0m0.136s
        506 balin:~
        |> 

OK, no this is really irritating -- why does it take between 0.5s and
1.5s to be able to tell me that it cannot actually check a missing
because the directory isn't a branch.  And why so variable in response
time?  This certainly should be an instantaneous, i.e. < 0.1s, sort of
activity.

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080909/b30d0462/attachment.pgp