[MERGE] Faster commit

[Ian Clatworthy]

Martin Pool wrote:
> On 6/4/07, Robert Collins <robertc at robertcollins.net> wrote:
>> On Mon, 2007-06-04 at 15:12 +1000, Ian Clatworthy wrote:
>> > The attached bundle speeds up commit, one of the areas of Bazaar
>> most in
>> > need of improvement for large trees. It has a noticeable impact: 50%
>> > quicker for small commits and up to the same for the initial commit.
>> >
>> > In summary, the changes do the following:
>> >
>> > 1. buffer the report of commit messages until the end
>>
>> I'm still very much against this. -1
> 
> I'm not sure what the "still" refers, maybe an off list mail?

No.

> I haven't read the code but just making it buffered does seem like a
> microoptimization to work around gnome-terminal.

Originally, I buffered because I thought that the intermittent writing
to ~/.bzr.log was causing the disk heads to move around far more than
necessary. We solved that by deciding that ~/.bzr.log didn't need to
have a record of what was committed, and writing to stderr/stdout was
sufficient.

Robert made the good point in an earlier email that, if buffering was
required for performance, it ought to be in the logging layer, not in
the UI layer. I agreed.

I then felt that buffering the messages was *semantically* correct
because commit really hadn't 'added foo', it had just recorded some info
about foo in a transaction that would commit foo later. After all, this
isn't CVS and our commits are atomic, right? If I hit Ctrl-C half way
through commit after I saw 'added foo', foo actually isn't committed
despite what it told me.

Robert disagreed with me (-1); I backed it out.

> Maybe we could write the changes to stdout rather than stderr, so it
> is buffered?

There is no difference in performance noticeable in stdout vs stderr.
Rather than change lots of tests, I left it as stderr. I'm not sure if
any of the GUI tools trap stderr output and report that as well. They
ought to go via the (Python) API but may not have that as a choice
depending on technology (e.g. Java?). If we want stdout because that's
the right thing to do, we can change it (and the tests).

> We identified in London that doing complete and accurate "what was
> committed" reports takes more significantly work than an optimal
> commit.  (With our current commit code and format, the difference is
> not so stark but I think it is still some more work.)  If we want to
> be fast it's not so great to do extra work by default.  So perhaps the
> changes should only be listed if you do commit -v, or at least
> disabled by commit -q.
> 

Robert and I played with this. -q doesn't work and I agreed to report
that as a bug. --no-verbose does work. There is certainly some room for
discussion here. For example, I'd still like to see the final message
('Committed rev xxx') even if -q was specified while others may think
otherwise.

Commit is in need of some serious restructuring. Notes I collected from
others are included in doc/developers in the patch. File formats are
also a big issue though I explicitly avoided that because there's plans
for that already.

Ian C.