On Tue, Oct 30, 2012 at 10:50:42AM +0100, [email protected] wrote:
> 'update-index --refresh' and 'diff-index' (without --cached) don't honor
> the core.preloadindex setting yet. Porcelain commands using these (such as
> git [svn] rebase) suffer from this, especially on Windows.
>
> Use read_cache_preload to improve performance.
>
> Additionally, in builtin/diff.c, don't preload index status if we don't
> access the working copy (--cached).
>
> Results with msysgit on WebKit repo (2GB in 200k files):
>
> | update-index | diff-index | rebase
> ----------------+--------------+------------+---------
> msysgit-v1.8.0 | 9.157s | 10.536s | 42.791s
> + preloadindex | 9.157s | 10.536s | 28.725s
> + this patch | 2.329s | 2.752s | 15.152s
> + fscache [1] | 0.731s | 1.171s | 8.877s
Cool numbers. On my quad-core SSD Linux box, I saw a few speedups, too.
Here are the numbers for "update-index --refresh" on the WebKit repo
(all are wall clock time, best-of-five):
| before | after
-----------+--------+--------
cold cache | 4.513s | 2.059s
warm cache | 0.252s | 0.164s
Not as dramatic, but still nice. I wonder how a spinning disk would fare
on the cold-cache case, though. I also tried it with all but one CPU
disabled, and the warm cache case was a little bit slower.
Still, I don't think we need to worry about performance regressions,
because people who don't have a setup suitable for it will not turn on
core.preloadindex in the first place. And if they have it on, the more
places we use it, probably the better.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
