git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
René Scharfe <l.s.r@web.de>
Date
Apr 27, 2019, 09:59 UTC
Message-ID
<f6f32bc0-109c-e0eb-f7d2-9e46647f260c@web.de>
In-Reply-To
<nycvar.QRO.7.76.6.1904261047560.45@tvgsbejvaqbjf.bet>
Am 26.04.19 um 16:51 schrieb Johannes Schindelin:> Hi Peff,
Show 19 quoted lines
>
> On Mon, 15 Apr 2019, Jeff King wrote:
>
>> On Sun, Apr 14, 2019 at 12:01:10AM +0200, René Scharfe wrote:
>>
>>>>> As we already link to the zlib library, we can perform the compression
>>>>> without even requiring gzip on the host machine.
>>>>
>>>> Very cool. It's nice to drop a dependency, and this should be a bit more
>>>> efficient, too.
>>>
>>> Getting rid of dependencies is good, and using zlib is the obvious way to
>>> generate .tgz files. Last time I tried something like that, a separate gzip
>>> process was faster, though -- at least on Linux [1].  How does this one
>>> fare?
>>
>> I'd expect a separate gzip to be faster in wall-clock time for a
>> multi-core machine, but overall consume more CPU. I'm slightly surprised
>> that your timings show that it actually wins on total CPU, too.

My initial expectation back then was that moving data between processes is costly and that compressing in-process would improve the overall performance. Your expectation is more in line with what I then actually saw. The difference in total CPU time wasn't that big, perhaps just noise.

> If performance is really a concern, you'll be much better off using `pigz`
> than `gzip`.

Performance is always a concern, but on the other hand I didn't see any complaints about slow archiving so far.

Show 14 quoted lines
>> Here are best-of-five times for "git archive --format=tar.gz HEAD" on
>> linux.git (the machine is a quad-core):
>>
>>    [before, separate gzip]
>>    real	0m21.501s
>>    user	0m26.148s
>>    sys	0m0.619s
>>
>>    [after, internal gzwrite]
>>    real	0m25.156s
>>    user	0m25.059s
>>    sys	0m0.096s
>>
>> which does show what I expect (longer overall, but less total CPU).
I get similar numbers with hyperfine:
Benchmark #1: git archive --format=tar.gz HEAD >/dev/null
  Time (mean ± σ):     16.683 s ±  0.451 s    [User: 20.230 s, System: 0.375 s]
  Range (min … max):   16.308 s … 17.852 s    10 runs
Benchmark #2: ~/src/git/git-archive --format=tar.gz HEAD >/dev/null
  Time (mean ± σ):     19.898 s ±  0.228 s    [User: 19.825 s, System: 0.073 s]
  Range (min … max):   19.627 s … 20.355 s    10 runs
Benchmark #3: git archive --format=zip HEAD >/dev/null
  Time (mean ± σ):     16.449 s ±  0.075 s    [User: 16.340 s, System: 0.109 s]
  Range (min … max):   16.326 s … 16.611 s    10 runs

#1 is git v2.21.0, #2 is with the two patches applied, #3 is v2.21.0 again, but with zip output, just to put things into perspective.

Show 11 quoted lines
>> Which one you prefer depends on your situation, of course. A user on a
>> workstation with multiple cores probably cares most about end-to-end
>> latency and using all of their available horsepower. A server hosting
>> repositories and receiving many unrelated requests probably cares more
>> about total CPU (though the differences there are small enough that it
>> may not even be worth having a config knob to un-parallelize it).
>
> I am a bit sad that this is so noticeable. Nevertheless, I think that
> dropping the dependency is worth it, in particular given that `gzip` is
> not exactly fast to begin with (you really should switch to `pigz` or to a
> faster compression if you are interested in speed).
We could import pigz verbatim, it's just 11K LOCs total. :)
Show 7 quoted lines
>>> 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. Is there a way? But it doesn't look too bad, and the performance is closer to using the real gzip:

Benchmark #1: ~/src/git/git-archive --format=tar.gz HEAD >/dev/null
  Time (mean ± σ):     17.300 s ±  0.198 s    [User: 20.825 s, System: 0.356 s]
  Range (min … max):   17.042 s … 17.638 s    10 runs
This is with the following patch:
---
 archive-tar.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 59 insertions(+), 4 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index 3e53aac1e6..c889b84c2c 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -38,11 +38,13 @@ static int write_tar_filter_archive(const struct archiver *ar,
 #define USTAR_MAX_MTIME 077777777777ULL
 #endif

+static int out_fd = 1;
+
 /* writes out the whole block, but only if it is full */
 static void write_if_needed(void)
 {
 	if (offset == BLOCKSIZE) {
-		write_or_die(1, block, BLOCKSIZE);
+		write_or_die(out_fd, block, BLOCKSIZE);
 		offset = 0;
 	}
 }
@@ -66,7 +68,7 @@ static void do_write_blocked(const void *data, unsigned long size)
 		write_if_needed();
 	}
 	while (size >= BLOCKSIZE) {
-		write_or_die(1, buf, BLOCKSIZE);
+		write_or_die(out_fd, buf, BLOCKSIZE);
 		size -= BLOCKSIZE;
 		buf += BLOCKSIZE;
 	}
@@ -101,10 +103,10 @@ static void write_trailer(void)
 {
 	int tail = BLOCKSIZE - offset;
 	memset(block + offset, 0, tail);
-	write_or_die(1, block, BLOCKSIZE);
+	write_or_die(out_fd, block, BLOCKSIZE);
 	if (tail < 2 * RECORDSIZE) {
 		memset(block, 0, offset);
-		write_or_die(1, block, BLOCKSIZE);
+		write_or_die(out_fd, block, BLOCKSIZE);
 	}
 }

@@ -434,6 +436,56 @@ static int write_tar_archive(const struct archiver *ar,
 	return err;
 }

+static int internal_gzip(int in, int out, void *data)
+{
+	int *levelp = data;
+	gzFile gzip = gzdopen(1, "wb");
+	if (!gzip)
+		die(_("gzdopen failed"));
+	if (gzsetparams(gzip, *levelp, Z_DEFAULT_STRATEGY) != Z_OK)
+		die(_("unable to set compression level"));
+
+	for (;;) {
+		char buf[BLOCKSIZE];
+		ssize_t read = xread(in, buf, sizeof(buf));
+		if (read < 0)
+			die_errno(_("read failed"));
+		if (read == 0)
+			break;
+		if (gzwrite(gzip, buf, read) != read)
+			die(_("gzwrite failed"));
+	}
+
+	if (gzclose(gzip) != Z_OK)
+		die(_("gzclose failed"));
+	close(in);
+	return 0;
+}
+
+static int write_tar_gzip_archive(const struct archiver *ar,
+				  struct archiver_args *args)
+{
+	struct async filter;
+	int r;
+
+	memset(&filter, 0, sizeof(filter));
+	filter.proc = internal_gzip;
+	filter.data = &args->compression_level;
+	filter.in = -1;
+
+	if (start_async(&filter))
+		die(_("unable to fork off internal gzip"));
+	out_fd = filter.in;
+
+	r = write_tar_archive(ar, args);
+
+	close(out_fd);
+	if (finish_async(&filter))
+		die(_("error in internal gzip"));
+
+	return r;
+}
+
 static int write_tar_filter_archive(const struct archiver *ar,
 				    struct archiver_args *args)
 {
@@ -445,6 +497,9 @@ static int write_tar_filter_archive(const struct archiver *ar,
 	if (!ar->data)
 		BUG("tar-filter archiver called with no filter defined");

+	if (!strcmp(ar->data, "gzip -cn"))
+		return write_tar_gzip_archive(ar, args);
+
 	strbuf_addstr(&cmd, ar->data);
 	if (args->compression_level >= 0)
 		strbuf_addf(&cmd, " -%d", args->compression_level);
--
2.21.0
Previous: Johannes SchindelinNext: René Scharfe
Message 22 of 74 in “Avoid spawning gzip in git archive”
  1. 0/2 Avoid spawning gzip in git archiveJohannes Schindelin via GitGitGadget, Apr 12, 2019
  2. 1/2 archive: replace write_or_die() calls with write_block_or_die()Rohit Ashiwal via GitGitGadget, Apr 12, 2019
  3. Jeff KingApr 13, 2019
  4. Junio C HamanoApr 13, 2019
  5. Rohit AshiwalApr 14, 2019
  6. Johannes SchindelinApr 26, 2019
  7. Junio C HamanoApr 26, 2019
  8. Johannes SchindelinApr 29, 2019
  9. Jeff KingMay 1, 2019
  10. René ScharfeMay 2, 2019
  11. Junio C HamanoMay 5, 2019
  12. Jeff KingMay 6, 2019
  13. Rohit AshiwalApr 14, 2019
  14. Junio C HamanoApr 14, 2019
  15. Johannes SchindelinApr 26, 2019
  16. Jeff KingMay 1, 2019
  17. 2/2 archive: avoid spawning `gzip`Rohit Ashiwal via GitGitGadget, Apr 12, 2019
  18. Jeff KingApr 13, 2019
  19. René ScharfeApr 13, 2019
  20. Jeff KingApr 15, 2019
  21. Johannes SchindelinApr 26, 2019
  22. René ScharfeApr 27, 2019
  23. René ScharfeApr 27, 2019
  24. Johannes SchindelinApr 29, 2019
  25. René ScharfeMay 1, 2019
  26. Jeff KingMay 1, 2019
  27. René ScharfeJun 10, 2019
  28. Jeff KingJun 13, 2019
  29. brian m. carlsonApr 13, 2019
  30. Jeff KingApr 15, 2019
  31. Johannes SchindelinApr 26, 2019
  32. Ævar Arnfjörð BjarmasonMay 2, 2019
  33. Johannes SchindelinMay 3, 2019
  34. Jeff KingMay 3, 2019
  35. Johannes SchindelinApr 26, 2019
  36. 0/5 Avoid spawning gzip in git archiveRené Scharfe, Jun 12, 2022
  37. 1/5 archive: rename archiver data field to filter_commandRené Scharfe, Jun 12, 2022
  38. 2/5 archive-tar: factor out write_block()René Scharfe, Jun 12, 2022
  39. 3/5 archive-tar: add internal gzip implementationRené Scharfe, Jun 12, 2022
  40. Junio C HamanoJun 13, 2022
  41. 4/5 archive-tar: use OS_CODE 3 (Unix) for internal gzipRené Scharfe, Jun 12, 2022
  42. 5/5 archive-tar: use internal gzip by defaultRené Scharfe, Jun 12, 2022
  43. Junio C HamanoJun 13, 2022
  44. Johannes SchindelinJun 14, 2022
  45. René ScharfeJun 14, 2022
  46. René ScharfeJun 14, 2022
  47. Johannes SchindelinJun 14, 2022
  48. René ScharfeJun 14, 2022
  49. Junio C HamanoJun 15, 2022
  50. Johannes SchindelinJun 14, 2022
  51. René ScharfeJun 14, 2022
  52. Johannes SchindelinJun 30, 2022
  53. Johannes SchindelinJul 1, 2022
  54. Jeff KingJul 1, 2022
  55. Junio C HamanoJul 1, 2022
  56. 0/6 Avoid spawning gzip in git archiveRené Scharfe, Jun 15, 2022
  57. 1/6 archive: update format documentationRené Scharfe, Jun 15, 2022
  58. 2/6 archive: rename archiver data field to filter_commandRené Scharfe, Jun 15, 2022
  59. 3/6 archive-tar: factor out write_block()René Scharfe, Jun 15, 2022
  60. 4/6 archive-tar: add internal gzip implementationRené Scharfe, Jun 15, 2022
  61. Ævar Arnfjörð BjarmasonJun 15, 2022
  62. René ScharfeJun 16, 2022
  63. Ævar Arnfjörð BjarmasonJun 24, 2022
  64. René ScharfeJun 24, 2022
  65. 5/6 archive-tar: use OS_CODE 3 (Unix) for internal gzipRené Scharfe, Jun 15, 2022
  66. 6/6 archive-tar: use internal gzip by defaultRené Scharfe, Jun 15, 2022
  67. René ScharfeMay 2, 2019
  68. René ScharfeMay 2, 2019
  69. Johannes SchindelinMay 8, 2019
  70. Jeff KingMay 8, 2019
  71. Johannes SchindelinMay 9, 2019
  72. Jeff KingMay 9, 2019
  73. René ScharfeMay 10, 2019
  74. Jeff KingMay 10, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.