From: Jeff King <peff@peff.net>
To: Fredrik Gustafsson <iveqy@iveqy.com>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
spearce@spearce.org, git@vger.kernel.org, pclouds@gmail.com
Subject: Re: [RFC] Add posibility to preload stat information.
Date: Wed, 20 Mar 2013 14:46:43 -0400 [thread overview]
Message-ID: <20130320184643.GA30165@sigill.intra.peff.net> (raw)
In-Reply-To: <20130320183641.GB32426@paksenarrion.iveqy.com>
On Wed, Mar 20, 2013 at 07:36:41PM +0100, Fredrik Gustafsson wrote:
> > Yes, I would certainly like my git startup time to be improved. But I
> > don't want to trade my hard drive's life for it.
>
> Does this really increase disk-reads? The fs-cache would make sure that
> the disk reads is almost the same, we only do them before we usually do
> them.
It shouldn't. But if you are running "stat" on every file in the repo
for each prompt, that is going to take measurable CPU time for large
repos (e.g., WebKit).
> > What I meant by "first time" is "chpwd() into the git repository, not
> > further chpwd()s when already inside the git repository".
>
> That's a good point. I'm not sure how to solve that though. Because it's
> not a fact that you always go to the root git-dir first.
>
> The only way I see this is with a lock-file that's kept and we only run
> git status every 5 minutes when doing something inside a work dir. That
> would add a lot of meta-data (the lock files), to store. (I hope I
> successfully explained that).
How about something like:
__git_primed_toplevel=
__git_prime_dir() {
local toplevel=`git rev-parse --show-toplevel 2>/dev/null`
if test -n "$toplevel" &&
test "$toplevel" != "$git_primed_toplevel"; then
git status >/dev/null 2>&1
git_primed_toplevel=$toplevel
fi
}
that would prime the whole repo the first time you enter it, but otherwise do
nothing (and you could run it from each prompt). If you switched back and forth
between two repos a lot, you would end up priming them both a lot, but that is
not that common a mode of operation (and you could keep an list of recently
primed repos instead of a single one, if you really wanted to deal with that).
You would also prime twice if you used two different terminals, but that's OK.
The subsequent ones are much faster due to disk cache, so this is really just
about not paying the extra stat penalty on _every_ prompt.
-Peff
prev parent reply other threads:[~2013-03-20 18:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 12:15 [RFC] Add posibility to preload stat information Fredrik Gustafsson
2013-03-20 16:48 ` Jeff King
2013-03-20 17:15 ` Junio C Hamano
2013-03-20 17:47 ` Jeff King
2013-03-21 10:41 ` Thomas Rast
2013-03-21 14:44 ` Junio C Hamano
2013-03-30 19:42 ` Phil Hord
2013-03-20 18:40 ` Fredrik Gustafsson
2013-03-20 17:15 ` Ramkumar Ramachandra
2013-03-20 17:41 ` Fredrik Gustafsson
2013-03-20 17:49 ` Ramkumar Ramachandra
2013-03-20 18:36 ` Fredrik Gustafsson
2013-03-20 18:46 ` Jeff King [this message]
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=20130320184643.GA30165@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=iveqy@iveqy.com \
--cc=pclouds@gmail.com \
--cc=spearce@spearce.org \
/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).