RFC: startup time - again

[David Cournapeau]

Robert Collins wrote:
>
> So would I. I'd also like to really put to bed some of the performance
> things that keep tripping us. It's totally ridiculous some of the things
> we find making bzr slow. Our tree access code is 3 times slower than a
> simple 'find' command.
>
> Naive pyrex code is only slightly faster than plain python. pyrex
> extensions actually need to be written to the python C api to be faster;
> and we're writing more and more of these things to get speed. They are
> also harder to profile (the python VM has to be loaded etc), harder to
> test|debug (can't step through it as easily, we're behind a layer the
> python debugger can't see, no easy hookup for gdb yet).
>   

Not that it would make the C difficulty issue irrelevant, but are you
aware of cython ? It is a (friendly) fork of pyrex, and supports some
things that pyrex does not, in particular wrt to debugging.

http://cython.org/

They presented some recent improvements at Scipy08 conference for source
code annotation with automatic highlight of hotspot, and those kind of
things to make it faster. Some people in the numpy and more generally
scientific python community like it.

But I am still unclear why bzr would need C whereas hg does not. I am a
bit skeptical about the fact that bzr higher abstractions than hg cost
so much. At least, from what I could read in this thread, I can't say I
have seen really tangible proof that C is needed.

Also, having a daemon / client architecture sounds horribly complicated;
at that stage, why not pushing something like bzr shell ?
 
cheers,

David