Re: [PATCH 2/2] archive: avoid spawning `gzip`

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 29, 2019, 21:25 UTC
Message-ID: <nycvar.QRO.7.76.6.1904291720120.45@tvgsbejvaqbjf.bet>
In-Reply-To: <45afd432-9e45-ea76-aa1b-e8cd1264e3a0@web.de>

Hi René,

On Sat, 27 Apr 2019, René Scharfe wrote:

Show 19 quoted lines

> Am 27.04.19 um 11:59 schrieb René Scharfe:> Am 26.04.19 um 16:51 schrieb
> Johannes Schindelin:
> >>
> >> On Mon, 15 Apr 2019, Jeff King wrote:
> >>
> >>> On Sun, Apr 14, 2019 at 12:01:10AM +0200, René Scharfe wrote:
> >>>
> >>>> Doing compression in its own thread may be a good idea.
> >>>
> >>> Yeah. It might even make the patch simpler, since I'd expect it to
> >>> be implemented with start_async() and a descriptor, making it look
> >>> just like a gzip pipe to the caller. :)
> >>
> >> Sadly, it does not really look like it is simpler.
> >
> > I have to agree -- at least I was unable to pull off the stdout
> > plumbing trick.
>
> The simplest solution is of course to not touch the archive code.

We could do that, of course, and we could avoid adding a new command that we have to support for eternity by introducing a command mode for `git archive` instead (think: `git archive --gzip -9`), and marking that command mode clearly as an internal implementation detail.

But since the performance is still not quite on par with `gzip`, I would actually rather not, and really, just punt on that one, stating that people interested in higher performance should use `pigz`.

And who knows, maybe nobody will complain at all about the performance? It's not like `gzip` is really, really fast (IIRC LZO blows gzip out of the water, speed-wise).

And if we get "bug" reports about this, we

1) have a very easy workaround:

	git config --global archive.tgz.command 'gzip -cn'

2) could always implement a pigz-like multi-threading solution.

I strongly expect a YAGNI here, though.

Ciao, Dscho