view mercurial/base85.c @ 29304:5e32852fa4bd

revset: make filteredset.__nonzero__ respect the order of the filteredset

This fix allows __nonzero__ to respect the direction of iteration of the
whole filteredset. Here's the case when it matters. Imagine that we have a
very large repository and we want to execute a command like:

    $ hg log --rev '(tip:0) and user(ikostia)' --limit 1

(we want to get the latest commit by me).

Mercurial will evaluate a filteredset lazy data structure, an
instance of the filteredset class, which will know that it has to iterate
in a descending order (isdescending() will return True if called). This
means that when some code iterates over the instance of this filteredset,
the 'and user(ikostia)' condition will be first checked on the latest
revision, then on the second latest and so on, allowing Mercurial to
print matches as it founds them. However, cmdutil.getgraphlogrevs
contains the following code:

    revs = _logrevs(repo, opts)
    if not revs:
        return revset.baseset(), None, None

The "not revs" expression is evaluated by calling filteredset.__nonzero__,
which in its current implementation will try to iterate the filteredset
in ascending order until it finds a revision that matches the 'and user(..'
condition. If the condition is only true on late revisions, a lot of
useless iterations will be done. These iterations could be avoided if
__nonzero__ followed the order of the filteredset, which in my opinion
is a sensible thing to do here.

The problem gets even worse when instead of 'user(ikostia)' some more
expensive check is performed, like grepping the commit diff.


I tested this fix on a very large repo where tip is my commit and my very
first commit comes fairly late in the revision history. Results of timing
of the above command on that very large repo.

-with my fix:
real    0m1.795s
user    0m1.657s
sys     0m0.135s

-without my fix:
real    1m29.245s
user    1m28.223s
sys     0m0.929s

I understand that this is a very specific kind of problem that presents
itself very rarely, only on very big repositories and with expensive
checks and so on. But I don't see any disadvantages to this kind of fix
either.

/*
 base85 codec

 Copyright 2006 Brendan Cully <[e-mail]>

 This software may be used and distributed according to the terms of
 the GNU General Public License, incorporated herein by reference.

 Largely based on git's implementation
*/

#define PY_SSIZE_T_CLEAN
#include <Python.h>

#include "util.h"

static const char b85chars[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
	"abcdefghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~";
static char b85dec[256];

static void b85prep(void)
{
	unsigned i;

	memset(b85dec, 0, sizeof(b85dec));
	for (i = 0; i < sizeof(b85chars); i++)
		b85dec[(int)(b85chars[i])] = i + 1;
}

static PyObject *b85encode(PyObject *self, PyObject *args)
{
	const unsigned char *text;
	PyObject *out;
	char *dst;
	Py_ssize_t len, olen, i;
	unsigned int acc, val, ch;
	int pad = 0;

	if (!PyArg_ParseTuple(args, "s#|i", &text, &len, &pad))
		return NULL;

	if (pad)
		olen = ((len + 3) / 4 * 5) - 3;
	else {
		olen = len % 4;
		if (olen)
			olen++;
		olen += len / 4 * 5;
	}
	if (!(out = PyBytes_FromStringAndSize(NULL, olen + 3)))
		return NULL;

	dst = PyBytes_AsString(out);

	while (len) {
		acc = 0;
		for (i = 24; i >= 0; i -= 8) {
			ch = *text++;
			acc |= ch << i;
			if (--len == 0)
				break;
		}
		for (i = 4; i >= 0; i--) {
			val = acc % 85;
			acc /= 85;
			dst[i] = b85chars[val];
		}
		dst += 5;
	}

	if (!pad)
		_PyBytes_Resize(&out, olen);

	return out;
}

static PyObject *b85decode(PyObject *self, PyObject *args)
{
	PyObject *out;
	const char *text;
	char *dst;
	Py_ssize_t len, i, j, olen, cap;
	int c;
	unsigned int acc;

	if (!PyArg_ParseTuple(args, "s#", &text, &len))
		return NULL;

	olen = len / 5 * 4;
	i = len % 5;
	if (i)
		olen += i - 1;
	if (!(out = PyBytes_FromStringAndSize(NULL, olen)))
		return NULL;

	dst = PyBytes_AsString(out);

	i = 0;
	while (i < len)
	{
		acc = 0;
		cap = len - i - 1;
		if (cap > 4)
			cap = 4;
		for (j = 0; j < cap; i++, j++)
		{
			c = b85dec[(int)*text++] - 1;
			if (c < 0)
				return PyErr_Format(
					PyExc_ValueError,
					"bad base85 character at position %d",
					(int)i);
			acc = acc * 85 + c;
		}
		if (i++ < len)
		{
			c = b85dec[(int)*text++] - 1;
			if (c < 0)
				return PyErr_Format(
					PyExc_ValueError,
					"bad base85 character at position %d",
					(int)i);
			/* overflow detection: 0xffffffff == "|NsC0",
			 * "|NsC" == 0x03030303 */
			if (acc > 0x03030303 || (acc *= 85) > 0xffffffff - c)
				return PyErr_Format(
					PyExc_ValueError,
					"bad base85 sequence at position %d",
					(int)i);
			acc += c;
		}

		cap = olen < 4 ? olen : 4;
		olen -= cap;
		for (j = 0; j < 4 - cap; j++)
			acc *= 85;
		if (cap && cap < 4)
			acc += 0xffffff >> (cap - 1) * 8;
		for (j = 0; j < cap; j++)
		{
			acc = (acc << 8) | (acc >> 24);
			*dst++ = acc;
		}
	}

	return out;
}

static char base85_doc[] = "Base85 Data Encoding";

static PyMethodDef methods[] = {
	{"b85encode", b85encode, METH_VARARGS,
	 "Encode text in base85.\n\n"
	 "If the second parameter is true, pad the result to a multiple of "
	 "five characters.\n"},
	{"b85decode", b85decode, METH_VARARGS, "Decode base85 text.\n"},
	{NULL, NULL}
};

#ifdef IS_PY3K
static struct PyModuleDef base85_module = {
	PyModuleDef_HEAD_INIT,
	"base85",
	base85_doc,
	-1,
	methods
};

PyMODINIT_FUNC PyInit_base85(void)
{
	b85prep();

	return PyModule_Create(&base85_module);
}
#else
PyMODINIT_FUNC initbase85(void)
{
	Py_InitModule3("base85", methods, base85_doc);

	b85prep();
}
#endif