view mercurial/exewrapper.c @ 30442:41a8106789ca

util: implement zstd compression engine Now that zstd is vendored and being built (in some configurations), we can implement a compression engine for zstd! The zstd engine is a little different from existing engines. Because it may not always be present, we have to defer load the module in case importing it fails. We facilitate this via a cached property that holds a reference to the module or None. The "available" method is implemented to reflect reality. The zstd engine declares its ability to handle bundles using the "zstd" human name and the "ZS" internal name. The latter was chosen because internal names are 2 characters (by only convention I think) and "ZS" seems reasonable. The engine, like others, supports specifying the compression level. However, there are no consumers of this API that yet pass in that argument. I have plans to change that, so stay tuned. Since all we need to do to support bundle generation with a new compression engine is implement and register the compression engine, bundle generation with zstd "just works!" Tests demonstrating this have been added. How does performance of zstd for bundle generation compare? On the mozilla-unified repo, `hg bundle --all -t <engine>-v2` yields the following on my i7-6700K on Linux: engine CPU time bundle size vs orig size throughput none 97.0s 4,054,405,584 100.0% 41.8 MB/s bzip2 (l=9) 393.6s 975,343,098 24.0% 10.3 MB/s gzip (l=6) 184.0s 1,140,533,074 28.1% 22.0 MB/s zstd (l=1) 108.2s 1,119,434,718 27.6% 37.5 MB/s zstd (l=2) 111.3s 1,078,328,002 26.6% 36.4 MB/s zstd (l=3) 113.7s 1,011,823,727 25.0% 35.7 MB/s zstd (l=4) 116.0s 1,008,965,888 24.9% 35.0 MB/s zstd (l=5) 121.0s 977,203,148 24.1% 33.5 MB/s zstd (l=6) 131.7s 927,360,198 22.9% 30.8 MB/s zstd (l=7) 139.0s 912,808,505 22.5% 29.2 MB/s zstd (l=12) 198.1s 854,527,714 21.1% 20.5 MB/s zstd (l=18) 681.6s 789,750,690 19.5% 5.9 MB/s On compression, zstd for bundle generation delivers: * better compression than gzip with significantly less CPU utilization * better than bzip2 compression ratios while still being significantly faster than gzip * ability to aggressively tune compression level to achieve significantly smaller bundles That last point is important. With clone bundles, a server can pre-generate a bundle file, upload it to a static file server, and redirect clients to transparently download it during clone. The server could choose to produce a zstd bundle with the highest compression settings possible. This would take a very long time - a magnitude longer than a typical zstd bundle generation - but the result would be hundreds of megabytes smaller! For the clone volume we do at Mozilla, this could translate to petabytes of bandwidth savings per year and faster clones (due to smaller transfer size). I don't have detailed numbers to report on decompression. However, zstd decompression is fast: >1 GB/s output throughput on this machine, even through the Python bindings. And it can do that regardless of the compression level of the input. By the time you have enough data to worry about overhead of decompression, you have plenty of other things to worry about performance wise. zstd is wins all around. I can't wait to implement support for it on the wire protocol and in revlogs.
author Gregory Szorc <gregory.szorc@gmail.com>
date Fri, 11 Nov 2016 01:10:07 -0800
parents 210bb28ca4fb
children 0241dd94ed38
line wrap: on
line source

/*
 exewrapper.c - wrapper for calling a python script on Windows

 Copyright 2012 Adrian Buehlmann <adrian@cadifra.com> and others

 This software may be used and distributed according to the terms of the
 GNU General Public License version 2 or any later version.
*/

#include <stdio.h>
#include <windows.h>

#include "hgpythonlib.h"

#ifdef __GNUC__
int strcat_s(char *d, size_t n, const char *s)
{
	return !strncat(d, s, n);
}
int strcpy_s(char *d, size_t n, const char *s)
{
	return !strncpy(d, s, n);
}
#endif


static char pyscript[MAX_PATH + 10];
static char pyhome[MAX_PATH + 10];
static char envpyhome[MAX_PATH + 10];
static char pydllfile[MAX_PATH + 10];

int main(int argc, char *argv[])
{
	char *p;
	int ret;
	int i;
	int n;
	char **pyargv;
	WIN32_FIND_DATA fdata;
	HANDLE hfind;
	const char *err;
	HMODULE pydll;
	void (__cdecl *Py_SetPythonHome)(char *home);
	int (__cdecl *Py_Main)(int argc, char *argv[]);

	if (GetModuleFileName(NULL, pyscript, sizeof(pyscript)) == 0)
	{
		err = "GetModuleFileName failed";
		goto bail;
	}

	p = strrchr(pyscript, '.');
	if (p == NULL) {
		err = "malformed module filename";
		goto bail;
	}
	*p = 0; /* cut trailing ".exe" */
	strcpy_s(pyhome, sizeof(pyhome), pyscript);

	hfind = FindFirstFile(pyscript, &fdata);
	if (hfind != INVALID_HANDLE_VALUE) {
		/* pyscript exists, close handle */
		FindClose(hfind);
	} else {
		/* file pyscript isn't there, take <pyscript>exe.py */
		strcat_s(pyscript, sizeof(pyscript), "exe.py");
	}

	pydll = NULL;
	/*
	We first check, that environment variable PYTHONHOME is *not* set.
	This just mimicks the behavior of the regular python.exe, which uses
	PYTHONHOME to find its installation directory (if it has been set).
	Note: Users of HackableMercurial are expected to *not* set PYTHONHOME!
	*/
	if (GetEnvironmentVariable("PYTHONHOME", envpyhome,
				   sizeof(envpyhome)) == 0)
	{
		/*
		Environment var PYTHONHOME is *not* set. Let's see if we are
		running inside a HackableMercurial.
		*/

		p = strrchr(pyhome, '\\');
		if (p == NULL) {
			err = "can't find backslash in module filename";
			goto bail;
		}
		*p = 0; /* cut at directory */

		/* check for private Python of HackableMercurial */
		strcat_s(pyhome, sizeof(pyhome), "\\hg-python");

		hfind = FindFirstFile(pyhome, &fdata);
		if (hfind != INVALID_HANDLE_VALUE) {
			/* path pyhome exists, let's use it */
			FindClose(hfind);
			strcpy_s(pydllfile, sizeof(pydllfile), pyhome);
			strcat_s(pydllfile, sizeof(pydllfile),
				 "\\" HGPYTHONLIB ".dll");
			pydll = LoadLibrary(pydllfile);
			if (pydll == NULL) {
				err = "failed to load private Python DLL "
				      HGPYTHONLIB ".dll";
				goto bail;
			}
			Py_SetPythonHome = (void*)GetProcAddress(pydll,
							"Py_SetPythonHome");
			if (Py_SetPythonHome == NULL) {
				err = "failed to get Py_SetPythonHome";
				goto bail;
			}
			Py_SetPythonHome(pyhome);
		}
	}

	if (pydll == NULL) {
		pydll = LoadLibrary(HGPYTHONLIB ".dll");
		if (pydll == NULL) {
			err = "failed to load Python DLL " HGPYTHONLIB ".dll";
			goto bail;
		}
	}

	Py_Main = (void*)GetProcAddress(pydll, "Py_Main");
	if (Py_Main == NULL) {
		err = "failed to get Py_Main";
		goto bail;
	}

	/*
	Only add the pyscript to the args, if it's not already there. It may
	already be there, if the script spawned a child process of itself, in
	the same way as it got called, that is, with the pyscript already in
	place. So we optionally accept the pyscript as the first argument
	(argv[1]), letting our exe taking the role of the python interpreter.
	*/
	if (argc >= 2 && strcmp(argv[1], pyscript) == 0) {
		/*
		pyscript is already in the args, so there is no need to copy
		the args and we can directly call the python interpreter with
		the original args.
		*/
		return Py_Main(argc, argv);
	}

	/*
	Start assembling the args for the Python interpreter call. We put the
	name of our exe (argv[0]) in the position where the python.exe
	canonically is, and insert the pyscript next.
	*/
	pyargv = malloc((argc + 5) * sizeof(char*));
	if (pyargv == NULL) {
		err = "not enough memory";
		goto bail;
	}
	n = 0;
	pyargv[n++] = argv[0];
	pyargv[n++] = pyscript;

	/* copy remaining args from the command line */
	for (i = 1; i < argc; i++)
		pyargv[n++] = argv[i];
	/* argv[argc] is guaranteed to be NULL, so we forward that guarantee */
	pyargv[n] = NULL;

	ret = Py_Main(n, pyargv); /* The Python interpreter call */

	free(pyargv);
	return ret;

bail:
	fprintf(stderr, "abort: %s\n", err);
	return 255;
}