Fossil SCM
`fossil annotate' is unusably slow
a82652e2216d2cf…
· opened 15 years ago
- Type
- Code_Defect
- Priority
- —
- Severity
- Critical
- Resolution
- Open
- Subsystem
- —
- Created
- March 25, 2011 1:42 a.m.
I downloaded the NetBSD fossil repository at
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 withcd 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.