我提供了一些基准测试结果，以比较到目前为止介绍的最著名的方法，即@bobince findnth()（基于str.split()）与@tgamblin find_nth()（或基于@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
当然，如果字符串很大，性能最重要，因此假设我们要在1.3 GB的文件“ bigfile”中找到第1000001个换行符（'\ n'）。为了节省内存，我们希望处理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，我的Macbook Air仍可容纳4 GB内存，因此让我们进行基准测试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()，这已经是我们第二次在after之后复制1.3 GB的数据了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
mmvs. 上似乎有一些小的性能损失s，但这表明find_nth()与1.2 s findnth的总和（47 s）相比，可以在1.2 s内获得答案。
我发现没有任何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级别没有差异。有趣的是_find_nth2()，它基于string.h的memchr()库函数，相对于以下简单的实现方式有所失落_find_nth()：额外的“优化” memchr()显然是后退式的...
总而言之，findnth()（基于str.split()）中的实现确实是一个坏主意，因为（a）由于需要进行复制，因此它对于较大的字符串表现出极大的性能，（b）根本不适用于mmap.mmap对象。在find_nth()（基于str.find()）中的实现在所有情况下都应优先考虑（因此是该问题的公认答案）。
还有很大的改进空间，因为C扩展比纯Python代码快将近4倍，这表明可能存在专用Python库函数的情况。