Benoît Dejean <[EMAIL PROTECTED]> writes:
[...]
> It looks CPU bounded, so i don't think. In the other thread i said
> that /2 the number of stat calls doesn't improve overall time on a
> local filesystem.
OK, that seems right. I'd expect for sufficiently large trees (for
some OSs) they'd be unable to cache the inodes, in which case removing
redundant stats would be an advantage. Maybe on NFS, too.
But if it's CPU bound, then it probably needs looking at. Presuming
inodeprints are being used, "mtn status" doesn't need to use the
database, I think: it just needs to stat, and read files in _MTN.
For net.venge.monotone, I find it takes about .5 seconds which is
fine. For another project ("mtn ls known|wc -l" gives 14507)
mtn status 2.50s user 0.16s system 99% cpu 2.683 total
and
git status 0.39s user 0.10s system 99% cpu 0.498 total
Both with a hot cache, obviously, so they're both CPU bound.
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
