From: Pete Wyckoff <pw@padd.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Karsten Blees <karsten.blees@gmail.com>,
kusmabite@gmail.com, Ramkumar Ramachandra <artagnon@gmail.com>,
Robert Zeh <robert.allan.zeh@gmail.com>,
finnag@pvv.org
Subject: Re: [PATCH v2] read_directory: avoid invoking exclude machinery on tracked files
Date: Sun, 17 Feb 2013 10:49:56 -0500 [thread overview]
Message-ID: <20130217154956.GA2395@padd.com> (raw)
In-Reply-To: <CACsJy8C9SGJxwnm1E2N_KyEMg5-MzDt2B+SrX7rygn8X1qq4Wg@mail.gmail.com>
pclouds@gmail.com wrote on Sun, 17 Feb 2013 11:39 +0700:
> On Sun, Feb 17, 2013 at 1:11 AM, Pete Wyckoff <pw@padd.com> wrote:
> > pclouds@gmail.com wrote on Sat, 16 Feb 2013 14:17 +0700:
> >> Finally some numbers (best of 20 runs) that shows why it's worth all
> >> the hassle:
> >>
> >> git status | webkit linux-2.6 libreoffice-core gentoo-x86
> >> -------------+----------------------------------------------
> >> before | 1.097s 0.208s 0.399s 0.539s
> >> after | 0.736s 0.159s 0.248s 0.501s
> >> nr. patterns | 89 376 19 0
> >> nr. tracked | 182k 40k 63k 101k
> >
> > Thanks for this work. I repeated some of the tests across NFS,
> > where I'd expect to see bigger differences.
>
> This is about reducing CPU processing time, not I/O time. So no bigger
> differences is expected. I/O time can be reduced with inotify, or fam
> in nfs case because inotify does not support nfs.
Numbers from the last mail were core.preloadindex=true. Here's
"time" output from average runs:
stock = 0m2.28s user 0m4.18s sys 0m11.28s elapsed 57.39 %CPU
duy = 0m1.25s user 0m4.43s sys 0m7.45s elapsed 76.41 %CPU
With this huge repo, preloadindex may be stressing directory
cache behavior on the NFS server or client. Your patch helps
both CPU and wait time by avoiding the 6000-odd open() of
non-existent .gitignore.
With core.preloadindex=false, it's a 1 sec speedup, all from CPU:
stock = 0m2.18s user 0m1.59s sys 0m7.78s elapsed 48.45 %CPU
duy = 0m1.17s user 0m1.63s sys 0m6.91s elapsed 40.59 %CPU
-- Pete
next prev parent reply other threads:[~2013-02-17 15:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-15 14:17 [PATCH] read_directory: avoid invoking exclude machinery on tracked files Nguyễn Thái Ngọc Duy
2013-02-15 16:52 ` Junio C Hamano
2013-02-15 18:30 ` Duy Nguyen
2013-02-15 19:32 ` Junio C Hamano
2013-02-16 3:31 ` Duy Nguyen
2013-02-18 16:42 ` Karsten Blees
2013-02-16 7:17 ` [PATCH v2] " Nguyễn Thái Ngọc Duy
2013-02-16 18:11 ` Pete Wyckoff
2013-02-17 4:39 ` Duy Nguyen
2013-02-17 15:49 ` Pete Wyckoff [this message]
2013-02-17 23:18 ` Junio C Hamano
2013-02-25 22:01 ` [PATCH/RFC] dir.c: Make git-status --ignored even more consistent Karsten Blees
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130217154956.GA2395@padd.com \
--to=pw@padd.com \
--cc=artagnon@gmail.com \
--cc=finnag@pvv.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karsten.blees@gmail.com \
--cc=kusmabite@gmail.com \
--cc=pclouds@gmail.com \
--cc=robert.allan.zeh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).