Re: MAINTAINERS file

[Miles Bader]

Thomas Lord <address@hidden> writes:
>> Geez, don't be silly Tom.  The problem is that the arch implementation
>> plays bugger-all attention to efficiency, 
>
> That's nonsense and (unintentionally, I assume) insulting.
>
> It pays quite a bit of attention to performance.

No insult was intended.  I like arch, I think it was a great design
(I still use tla daily!), and I have great respect for you.

However, in practice, tla often feels more like a proof-of-concept than
something which has had real attention paid to performance and
optimization.  Git development _has_ paid real attention to performance,
and it really shows.

[I'm not attempting to distinguish between inherent slowness (where
speed is hobbled by the underlying design) and lack of optimization,
merely observing that in practice, tla is slow.  No doubt there are
elements of both involved.]

> There is some old mailing list message from Linus, around the
> time git was launched, that drives most of that.   His very narrow
> aim (in the area it differs from Arch) was to make "commit"
> times as quick as possible.   That was, more or less, his specific
> excuse for not using arch rather than writing git.
>
> Commit times are a strange metric to optimize for in a changeset-oriented
> system.   There are plenty of other design goals and constraints to
> consider.
>
> Why not look at check-out times or file retrieval times?
> In many situations, for Arch, those are between O(1)
> and O(n) where n is the number of bytes in the revision?

I'm not talking about commit times.  I'm talking about basically _every_
operation which I do on a regular basic (e.g. update working dir, merge
other branch, do file/tree diff, commit) .  Git is really, _really_
fast.  Scary fast.  Tla is almost always palpably "slow", even when the
repository is on local disk and the revision library has every
applicable revision.  I still use, of course, so obviously it's in the
realm of "acceptable", but I've become accustomed to waiting.

> Or, if you really want git-speed (or better) commit times
> for arch -- that can be done with some *modest* coding
> by "committing to the revision library" and computing
> the changeset more lazily.

I'm sure there are many things that could be done to optimize tla and
speed things up.  Indeed, mostly what I'm trying to say is that
by-and-large, that work _hasn't been done_ on tla, and it _has_ been
done on git, and this fact is very obvious when using these systems.

In part this is a historical accident -- git happened to come of age in
a community where there are lots and lots of performance-obsessed people
well acquainted with the things you need to do to really make things
fast (and of course it's no accident that it's _fastest_ on a system
with a linux kernel...), and willing to put in the effort to make it so.

-Miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]