On Tue, Oct 30, 2012 at 10:50:42AM +0100, karsten.bl...@dcon.de 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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to