On Thu, 5 Apr 2007, Nicolas Pitre wrote:
>
> For example I think there might be ways to improve the pack mmap
> windowing, or git-fsck's IO patterns. For example, git-fsck --full
> spend 96% of the time waiting for IO completion and only 4% actually
> performing some work according to top. At that rate that makes fsck
> --full rather unusable on this repo. Without --full then fsck completes
> in less than 2 seconds.
Without "--full", it doesn't actually really do anything much, since it
will basically ignore objects that are in the pack.
With --full, there are certainly things that we could improve upon. We
currently tend to walk things a few times for pack contents:
- first we do the SHA1 of the full pack
- then we go back, and unpack and fsck each entry in the pack.
So if the pack-file is too big to fit in memory, we'll basically always
read it at least twice (and that's ignoring the fact that delta lookup
will obviously seek back and forth, which makes access patterns worse).
On the other hand, there's a perfectly good reason why we don't actually
fsck pack-files by default. They're "stable storage". You don't normally
need to. So I'd not worry too much about fsck performance. I suspect
you'll find that with 1GB or RAM you'll have other performance problems
that are more pressing ("git clone" comes to mind ;)
Me, I'm just 53% done with the download, so I probably won't be looking at
this today ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html