git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Pratyush Yadav <me@yadavpratyush.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Bert Wesarg <bert.wesarg@googlemail.com>,
	Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 1/1] respect core.hooksPath, falling back to .git/hooks
Date: Tue, 1 Oct 2019 19:01:12 +0530	[thread overview]
Message-ID: <20191001133112.3qh4aeoctkoz2wxy@yadavpratyush.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1909301139460.46@tvgsbejvaqbjf.bet>

On 30/09/19 11:42AM, Johannes Schindelin wrote:
> On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > On Fri, Sep 27, 2019 at 12:40 AM Pratyush Yadav <me@yadavpratyush.com> wrote:
> > > > gitdir is used in a lot of places, and I think all those would 
> > > > also
> > > > benefit from using --git-path. So I think it is a better idea to move
> > > > this to the procedure gitdir. It would have to be refactored to take any
> > > > number of arguments, instead of the two it takes here.
> 
> The `gitdir` function is called 13 times during startup alone, and who
> knows how many more times later.
> 
> So I am quite convinced that the original intention was to save on
> spawning processes left and right.
> 
> But since you are the Git GUI maintainer, and this was your suggestion,
> I made it so.

Yes, I am the maintainer, but I am not an all-knowing, all-seeing 
entity. Your, and every other contributors, suggestions are very 
valuable. And my suggestions aren't gospel. I would hate to see someone 
send in a patch they weren't sure was the best thing to do just because 
I suggested it. Please feel free to object my suggestions.

In this case, I didn't expect gitdir to be called this many times.

While I don't notice much of a performance difference on my system 
(Linux), a quick measurement tells me that the time spent in gitdir is 
about 16 ms. In contrast, the same measurement without the v2 patch 
gives out 0 ms (IOW, very fast). 16 ms sounds a bit much for something 
so simple. It might not be the same for everyone else. AFAIK, spawning a 
process is much slower on Windows.

So now I'm not so sure my suggestion was a good one. My original aim was 
to be sure everything was correct, and no incorrect directories were 
being used. But the current solution comes at a performance hit.

> > > We could either maintain a blacklist, for what we cache the result
> > > too, or always call "git rev-parse --git-dir".
> > >
> > > This blacklist would need to be in sync with the one in Git's
> > > path.c::adjust_git_path() than.

Bert's suggestion seems like a decent compromise. We run `git rev-parse 
--git-path` for the paths in the blacklist, and for the rest we use the 
cached value. This does run the risk of getting out of sync with 
git.git's list, but it might be better than spawing a process every 
time, and is very likely better than just doing it for hooks.

Thoughts?

-- 
Regards,
Pratyush Yadav

  reply	other threads:[~2019-10-01 13:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 21:17 [PATCH 0/1] git-gui: respect core.hooksPath, falling back to .git/hooks Johannes Schindelin via GitGitGadget
2019-09-26 21:17 ` [PATCH 1/1] " Johannes Schindelin via GitGitGadget
2019-09-26 22:36   ` Pratyush Yadav
2019-09-27  6:10     ` Bert Wesarg
2019-09-27 13:05       ` Pratyush Yadav
2019-09-30  9:42         ` Johannes Schindelin
2019-10-01 13:31           ` Pratyush Yadav [this message]
2019-10-01 17:38             ` Johannes Schindelin
2019-10-04 16:48               ` Pratyush Yadav
2019-10-04 19:56                 ` Johannes Schindelin
2019-09-30  9:45 ` [PATCH v2 0/1] git-gui: " Johannes Schindelin via GitGitGadget
2019-09-30  9:45   ` [PATCH v2 1/1] " Johannes Schindelin via GitGitGadget
2019-10-04 21:41   ` [PATCH v3 0/1] git-gui: " Johannes Schindelin via GitGitGadget
2019-10-04 21:41     ` [PATCH v3 1/1] Fix gitdir e.g. to respect core.hooksPath Johannes Schindelin via GitGitGadget
2019-10-08  0:29       ` Pratyush Yadav
2019-10-08 11:30         ` Johannes Schindelin
2019-10-08 11:33     ` [PATCH v4 0/1] git-gui: respect core.hooksPath, falling back to .git/hooks Johannes Schindelin via GitGitGadget
2019-10-08 11:33       ` [PATCH v4 1/1] Make gitdir work with worktrees, respect core.hooksPath, etc Johannes Schindelin via GitGitGadget
2019-10-11 22:26         ` Pratyush Yadav
2019-10-12 21:24           ` Johannes Schindelin
2019-10-13 18:55             ` Pratyush Yadav
2019-10-13 22:18               ` Johannes Schindelin
2019-10-17 18:34                 ` Pratyush Yadav
2019-10-14  8:14               ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191001133112.3qh4aeoctkoz2wxy@yadavpratyush.com \
    --to=me@yadavpratyush.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=bert.wesarg@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).