Я предлагаю некоторые результаты сравнительного анализа, сравнивающие наиболее известные подходы, представленные до сих пор, а именно findnth()
@bobince (на основе str.split()
) и find_nth()
@tgamblin или @Mark Byers (на основе str.find()
). Я также сравню с расширением C (_find_nth.so
), чтобы увидеть, насколько быстро мы можем работать. Вот find_nth.py
:
def findnth(haystack, needle, n):
parts= haystack.split(needle, n+1)
if len(parts)<=n+1:
return -1
return len(haystack)-len(parts[-1])-len(needle)
def find_nth(s, x, n=0, overlap=False):
l = 1 if overlap else len(x)
i = -l
for c in xrange(n + 1):
i = s.find(x, i + l)
if i < 0:
break
return i
Конечно, производительность имеет наибольшее значение, если строка большая, поэтому предположим, что мы хотим найти 1000001-й символ новой строки ('\n') в 1,3-гигабайтном файле с именем 'bigfile'. Чтобы сэкономить память, мы хотели бы работать с mmap.mmap
объектным представлением файла:
In [1]: import _find_nth, find_nth, mmap
In [2]: f = open('bigfile', 'r')
In [3]: mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
Уже есть первая проблема с findnth()
, так как объекты mmap.mmap
не поддерживают split()
. Таким образом, нам фактически нужно скопировать весь файл в память:
In [4]: %time s = mm[:]
CPU times: user 813 ms, sys: 3.25 s, total: 4.06 s
Wall time: 17.7 s
Ой! К счастью, s
все еще умещается в 4 ГБ памяти моего Macbook Air, поэтому давайте сравним findnth()
:
In [5]: %timeit find_nth.findnth(s, '\n', 1000000)
1 loops, best of 3: 29.9 s per loop
Явно ужасное выступление. Давайте посмотрим, как работает подход, основанный на str.find()
:
In [6]: %timeit find_nth.find_nth(s, '\n', 1000000)
1 loops, best of 3: 774 ms per loop
Намного лучше! Ясно, что проблема findnth()
заключается в том, что он вынужден копировать строку во время split()
, а это уже второй раз, когда мы копировали 1,3 ГБ данных примерно после s = mm[:]
. Здесь проявляется второе преимущество find_nth()
: мы можем использовать его непосредственно на mm
, так что требуется ноль копий файла:
In [7]: %timeit find_nth.find_nth(mm, '\n', 1000000)
1 loops, best of 3: 1.21 s per loop
Похоже, что при работе с mm
по сравнению с s
наблюдается небольшое снижение производительности, но это показывает, что find_nth()
может дать нам ответ за 1,2 с по сравнению с findnth
в общей сложности 47 с.
Я не нашел случаев, когда подход, основанный на str.find()
, был значительно хуже, чем подход, основанный на str.split()
, поэтому на данный момент я бы сказал, что ответ @tgamblin или @Mark Byers должен быть принят вместо ответа @bobince.
В моем тестировании версия find_nth()
выше была самым быстрым решением для чистого Python, которое я мог придумать (очень похоже на версию @Mark Byers). Давайте посмотрим, насколько лучше мы можем работать с модулем расширения C. Вот _find_nthmodule.c
:
#include <Python.h>
#include <string.h>
off_t _find_nth(const char *buf, size_t l, char c, int n) {
off_t i;
for (i = 0; i < l; ++i) {
if (buf[i] == c && n-- == 0) {
return i;
}
}
return -1;
}
off_t _find_nth2(const char *buf, size_t l, char c, int n) {
const char *b = buf - 1;
do {
b = memchr(b + 1, c, l);
if (!b) return -1;
} while (n--);
return b - buf;
}
/* mmap_object is private in mmapmodule.c - replicate beginning here */
typedef struct {
PyObject_HEAD
char *data;
size_t size;
} mmap_object;
typedef struct {
const char *s;
size_t l;
char c;
int n;
} params;
int parse_args(PyObject *args, params *P) {
PyObject *obj;
const char *x;
if (!PyArg_ParseTuple(args, "Osi", &obj, &x, &P->n)) {
return 1;
}
PyTypeObject *type = Py_TYPE(obj);
if (type == &PyString_Type) {
P->s = PyString_AS_STRING(obj);
P->l = PyString_GET_SIZE(obj);
} else if (!strcmp(type->tp_name, "mmap.mmap")) {
mmap_object *m_obj = (mmap_object*) obj;
P->s = m_obj->data;
P->l = m_obj->size;
} else {
PyErr_SetString(PyExc_TypeError, "Cannot obtain char * from argument 0");
return 1;
}
P->c = x[0];
return 0;
}
static PyObject* py_find_nth(PyObject *self, PyObject *args) {
params P;
if (!parse_args(args, &P)) {
return Py_BuildValue("i", _find_nth(P.s, P.l, P.c, P.n));
} else {
return NULL;
}
}
static PyObject* py_find_nth2(PyObject *self, PyObject *args) {
params P;
if (!parse_args(args, &P)) {
return Py_BuildValue("i", _find_nth2(P.s, P.l, P.c, P.n));
} else {
return NULL;
}
}
static PyMethodDef methods[] = {
{"find_nth", py_find_nth, METH_VARARGS, ""},
{"find_nth2", py_find_nth2, METH_VARARGS, ""},
{0}
};
PyMODINIT_FUNC init_find_nth(void) {
Py_InitModule("_find_nth", methods);
}
Вот файл setup.py
:
from distutils.core import setup, Extension
module = Extension('_find_nth', sources=['_find_nthmodule.c'])
setup(ext_modules=[module])
Устанавливайте как обычно с python setup.py install
. Код C здесь имеет преимущество, поскольку он ограничен поиском отдельных символов, но давайте посмотрим, насколько это быстро:
In [8]: %timeit _find_nth.find_nth(mm, '\n', 1000000)
1 loops, best of 3: 218 ms per loop
In [9]: %timeit _find_nth.find_nth(s, '\n', 1000000)
1 loops, best of 3: 216 ms per loop
In [10]: %timeit _find_nth.find_nth2(mm, '\n', 1000000)
1 loops, best of 3: 307 ms per loop
In [11]: %timeit _find_nth.find_nth2(s, '\n', 1000000)
1 loops, best of 3: 304 ms per loop
Явно еще немного быстрее. Интересно, что на уровне C нет разницы между вариантами in-memory и mmapped. Также интересно видеть, что _find_nth2()
, основанный на библиотечной функции memchr()
string.h
, проигрывает простой реализации в _find_nth()
: дополнительные "оптимизации" в memchr()
, по-видимому, имеют неприятные последствия...
В заключение, реализация в findnth()
(на основе str.split()
) действительно плохая идея, поскольку (а) она ужасно работает для больших строк из-за необходимого копирования и (б) она вообще не работает с объектами mmap.mmap
. Реализация в find_nth()
(на основе str.find()
) должна быть предпочтительной при любых обстоятельствах (и, следовательно, быть принятым ответом на этот вопрос).
Есть еще много возможностей для улучшения, поскольку расширение C работало почти в 4 раза быстрее, чем чистый код Python, что указывает на то, что может быть случай для специальной библиотечной функции Python.
person
Stefan
schedule
05.05.2014