On Tue, Oct 30, 2012 at 10:50 AM, <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):
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):
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.
On Fri, Nov 02, 2012 at 11:26:16AM -0400, Jeff King wrote:
> 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.
BTW, your patch was badly damaged in transit (wrapped, and tabs
converted to spaces). I was able to fix it up, but please check your
mailer's settings.
karsten.bl...@dcon.de writes:
> Jeff King <p...@peff.net> wrote on 02.11.2012 16:38:00:
>> On Fri, Nov 02, 2012 at 11:26:16AM -0400, Jeff King wrote:
>> > 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.
>> BTW, your patch was badly damaged in transit (wrapped, and tabs
>> converted to spaces). I was able to fix it up, but please check your
>> mailer's settings.
> Yes, I feared as much, that's why I included the pull URL (the company MTA > only accepts outbound mail from Notes clients, sorry).
> Is there a policy for people with broken mailers (send patch as > attachment, add pull URL more prominently, don't include plaintext patch > at all...)?
If anything, "fix your mailer" probably is the policy you are
looking for, I think.
> If anything, "fix your mailer" probably is the policy you are
> looking for, I think.
Well then...I've cloned myself @gmail, I hope this is better.
Just some provoking thoughts...(if I may):
RFC-5322 recommends wrapping lines at 78, and mail relays and gateways are allowed to change message content according to the capabilities of the receiver (RFC-5598). In essence, plaintext mail is completely unsuitable for preformatted text such as source code.
On the other hand, git tries to solve the very problem of distributed source code management, and consistency by strong sha-1 checksums is on the top of the feature list.
It is somehow hard to believe that contributing to git itself should only be possible using the most unreliable of protocols. Don't you trust your own software?
-- >8 --
Subject: [PATCH] update-index/diff-index: use core.preloadindex to improve performance
'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):