Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: May 21, 2007, 15:17 UTC
Message-ID: <b0943d9e0705210817n35e50a6bgb519b693984b3a4b@mail.gmail.com>
In-Reply-To: <20070521113915.GA3090@diana.vm.bytemark.co.uk>

On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:

Show 5 quoted lines

> On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote:
>
> > We might consider having plumbing written in C or something, and
> > make sure that the plumbing can be called directly if there's need,
> > but it's going to complicate things greatly compared to pure Python.

Yes, it will complicate things. I think StGIT would have progressed at a much slower pace if written in C :-).

Show 5 quoted lines

> What I'm (foggily) envisioning here is to rewrite parts of StGIT (as
> little as possible) as a C library (libstgit.so?), and call the
> library both from the Python code, and from a "plumbing" C program
> (stgit-helper?). We should not try to make the library API stable,
> just like the current git library.

Apart from the start-up time, I don't see other major slowdowns caused by Python. It would be useful to use a git library directly without invoking external applications (I'm not sure what's the state of a "libgit.a" or what improvement we would get).

As for the start-up time, unless you write most of the commands in C, we would still have to load Python modules. If you run stg-prof instead of stg for a simple command like 'top', you can see that the main function takes about 60-70ms, the rest to 150ms reported by the external 'time' is Python start-up and module loading.

I had a quick try at using "freeze.py" to generate a binary (well, it includes python bytecodes but it might save time on module look-up) but it got confused by my optimisation to only load module commands based on the stg arguments. Maybe we should try this first.

Show 5 quoted lines

> There are two kinds of things we'd want to have in the library: (1)
> things that are too slow to do in Python, and (2) things that need to
> be available from stgit-helper in order to avoid Python's startup
> cost, such as top/applied/unapplied for the bash completion and bash
> prompt.

As you probably guessed, I'm not really in favour of re-writing parts of StGIT in C, at least not in the near future, though anyone can fork and re-implement it :-).

-- 
Catalin