All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <johannes.schindelin@gmx.de>
Cc: Paul Tan <pyokagan@gmail.com>, Yurii Shevtsov <ungetch@gmail.com>,
	Git List <git@vger.kernel.org>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [GSoC] Applying for conversion scripts to builtins
Date: Tue, 17 Mar 2015 11:38:39 -0700	[thread overview]
Message-ID: <xmqqpp87o4eo.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <4355599932558291b22313f244eda9bd@www.dscho.org> (Johannes Schindelin's message of "Tue, 17 Mar 2015 12:56:15 +0100")

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> Therefore, I would wager a bet that just the mere conversion of a
> shell script into even a primitive `run_command()`-based builtin would
> help performance on Windows in a noticeable manner.

As you correctly allege, if a patch rewrote a shell-scripted
porcelain by using series of run_command() and doing nothing else, I
would have asked "is that an improvement?", without knowing that.

> Of course, it would be *even nicer* to avoid the spawning altogether.

Yeah, that, too ;-)

> The biggest benefit of avoiding needless parsing, however, is not
> performance. It is avoiding quoting issues. This is particularly so on
> Windows, where Git is sometimes called from outside a shell
> environment, where we have to deal with inconsistent quoting because
> it is every Windows program's own job to parse the command-line,
> including the quoting.
>
> Concrete example: on Windows, we have file locking issues because
> files that are in use cannot be deleted. For that reason, we have
> Windows-specific code that is "nice" by trying harder to delete files,
> giving programs a little time to let their locks go. This locking
> issue happens also when a virus scanner "uses"...

These are definitely good advices from the area expert.

Thanks for a bunch of good input.

      reply	other threads:[~2015-03-17 18:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16 16:49 [GSoC] Applying for conversion scripts to builtins Yurii Shevtsov
2015-03-16 18:03 ` Matthieu Moy
2015-03-17  0:22 ` Paul Tan
2015-03-17  1:34   ` Duy Nguyen
2015-03-17 11:56   ` Johannes Schindelin
2015-03-17 18:38     ` Junio C Hamano [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=xmqqpp87o4eo.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=pyokagan@gmail.com \
    --cc=ungetch@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.