<http://ftp.NetBSD.org/pub/NetBSD/misc/repositories/fossil/src.fossil>,

opened it with `fossil open ../src.fossil', chose a file at random, and tried to annotate it with `cd src/sys/dev/usb && fossil annotate uark.c'. It took over an hour before `fossil annotate' began to write any output.

Around forty minutes in, I ktraced the fossil process for a minute or so, which revealed that almost everything it was doing was pwrite. iostat reported that it was hammering the disk -- writing 20 megabytes per second. (Nothing else on the machine was doing substantial disk I/O then.)

After it completed, I started it up again with `fossil --sqltrace annotate uark.c', and all the output I have seen so far is of the form

SELECT a.pid, b.mtime FROM plink a LEFT JOIN plink b ON b.cid=a.pid WHERE a.cid=N; INSERT OR IGNORE INTO ok VALUES(M);

where N and M are positive integers that are nearby one another and both are decrementing but don't seem to be equal.

anonymous added on 2011-06-02 04:08:31 UTC:
I noticed that fossil prefers using /var/tmp over /tmp for temporary storage, in file.c and sqlite3.c. This strikes me as strange: why would fossil (and sqlite3 in general) want its temporary storage to persist across reboots?

Setting TMPDIR=/tmp made `fossil annotate' run tremendously faster for me, since my /tmp is a RAM-backed file system while my /var/tmp is a synchronous disk-backed file system on this machine -- the total time reduced from an hour to two and a half minutes. Two and a half minutes is still pretty slow, though.

While looking at this, I noticed that file_tempname in file.c does not appear to respect the TMPDIR environment variable at all. Fortunately, this routine appears to be used only by `fossil diff' and only when an external diff program is configured.