ทำไม 'x' in ('x',) เร็วกว่า 'x' == 'x'


274
>>> timeit.timeit("'x' in ('x',)")
0.04869917374131205
>>> timeit.timeit("'x' == 'x'")
0.06144205736110564

ใช้ได้กับสิ่งอันดับด้วยหลายองค์ประกอบทั้งสองเวอร์ชันดูเหมือนจะเติบโตเป็นเส้นตรง:

>>> timeit.timeit("'x' in ('x', 'y')")
0.04866674801541748
>>> timeit.timeit("'x' == 'x' or 'x' == 'y'")
0.06565782838087131
>>> timeit.timeit("'x' in ('y', 'x')")
0.08975995576448526
>>> timeit.timeit("'x' == 'y' or 'x' == 'y'")
0.12992391047427532

จากนี้ผมคิดว่าผมควรจะโดยสิ้นเชิงเริ่มใช้inทุกแทน==!


167
ในกรณีที่: โปรดอย่าเริ่มใช้ทุกแทนin ==มันเป็นการเพิ่มประสิทธิภาพก่อนวัยอันควรที่เป็นอันตรายต่อการอ่าน
พันเอกสามสิบสอง

4
ลอง x ="!foo" x in ("!foo",)และx == "!foo"
Padraic Cunningham

2
A ใน B = ค่า, C == D ค่าและการเปรียบเทียบประเภท
dsgdfg

6
วิธีการที่สมเหตุสมผลมากกว่าการใช้inแทนที่จะ==เปลี่ยนเป็น C.
Mad Physicist

1
หากคุณเขียนด้วย Python และคุณเลือกโครงสร้างหนึ่งเพื่อสร้างความรวดเร็วคุณจะทำผิด
Veky

คำตอบ:


257

ดังที่ฉันได้พูดกับ David Wolever มีสิ่งนี้มากกว่าที่เห็น ทั้งสองวิธีส่งไปยังis; คุณสามารถพิสูจน์ได้โดยทำ

min(Timer("x == x", setup="x = 'a' * 1000000").repeat(10, 10000))
#>>> 0.00045456900261342525

min(Timer("x == y", setup="x = 'a' * 1000000; y = 'a' * 1000000").repeat(10, 10000))
#>>> 0.5256857610074803

คนแรกสามารถทำได้อย่างรวดเร็วเพียงเพราะมันตรวจสอบตามตัวตน

เพื่อหาสาเหตุที่จะใช้เวลานานกว่าอีกลองมาติดตามการดำเนินการ

พวกเขาทั้งสองเริ่มceval.cจากCOMPARE_OPนับว่าเป็น bytecode ที่เกี่ยวข้อง

TARGET(COMPARE_OP) {
    PyObject *right = POP();
    PyObject *left = TOP();
    PyObject *res = cmp_outcome(oparg, left, right);
    Py_DECREF(left);
    Py_DECREF(right);
    SET_TOP(res);
    if (res == NULL)
        goto error;
    PREDICT(POP_JUMP_IF_FALSE);
    PREDICT(POP_JUMP_IF_TRUE);
    DISPATCH();
}

สิ่งนี้จะปรากฏค่าจากสแต็ก (โดยทางเทคนิคแล้วจะปรากฏเพียงหนึ่งค่า)

PyObject *right = POP();
PyObject *left = TOP();

และทำการเปรียบเทียบ:

PyObject *res = cmp_outcome(oparg, left, right);

cmp_outcome นี่คือ:

static PyObject *
cmp_outcome(int op, PyObject *v, PyObject *w)
{
    int res = 0;
    switch (op) {
    case PyCmp_IS: ...
    case PyCmp_IS_NOT: ...
    case PyCmp_IN:
        res = PySequence_Contains(w, v);
        if (res < 0)
            return NULL;
        break;
    case PyCmp_NOT_IN: ...
    case PyCmp_EXC_MATCH: ...
    default:
        return PyObject_RichCompare(v, w, op);
    }
    v = res ? Py_True : Py_False;
    Py_INCREF(v);
    return v;
}

นี่คือที่แยกเส้นทาง PyCmp_INสาขาไม่

int
PySequence_Contains(PyObject *seq, PyObject *ob)
{
    Py_ssize_t result;
    PySequenceMethods *sqm = seq->ob_type->tp_as_sequence;
    if (sqm != NULL && sqm->sq_contains != NULL)
        return (*sqm->sq_contains)(seq, ob);
    result = _PySequence_IterSearch(seq, ob, PY_ITERSEARCH_CONTAINS);
    return Py_SAFE_DOWNCAST(result, Py_ssize_t, int);
}

โปรดทราบว่า tuple ถูกกำหนดเป็น

static PySequenceMethods tuple_as_sequence = {
    ...
    (objobjproc)tuplecontains,                  /* sq_contains */
};

PyTypeObject PyTuple_Type = {
    ...
    &tuple_as_sequence,                         /* tp_as_sequence */
    ...
};

ดังนั้นสาขา

if (sqm != NULL && sqm->sq_contains != NULL)

จะถูกนำมาและ*sqm->sq_containsซึ่งเป็นฟังก์ชั่น(objobjproc)tuplecontainsจะถูกนำ

สิ่งนี้ทำ

static int
tuplecontains(PyTupleObject *a, PyObject *el)
{
    Py_ssize_t i;
    int cmp;

    for (i = 0, cmp = 0 ; cmp == 0 && i < Py_SIZE(a); ++i)
        cmp = PyObject_RichCompareBool(el, PyTuple_GET_ITEM(a, i),
                                           Py_EQ);
    return cmp;
}

... เดี๋ยวก่อนPyObject_RichCompareBoolใช่ไหมที่สาขาอื่นใช้ Nope PyObject_RichCompareว่าเป็น

เส้นทางโค้ดนั้นสั้นดังนั้นจึงน่าจะเป็นความเร็วของทั้งสองนี้ มาเปรียบเทียบกัน

int
PyObject_RichCompareBool(PyObject *v, PyObject *w, int op)
{
    PyObject *res;
    int ok;

    /* Quick result when objects are the same.
       Guarantees that identity implies equality. */
    if (v == w) {
        if (op == Py_EQ)
            return 1;
        else if (op == Py_NE)
            return 0;
    }

    ...
}

เส้นทางรหัสในPyObject_RichCompareBoolสวยมากยุติทันที สำหรับPyObject_RichCompareมัน

PyObject *
PyObject_RichCompare(PyObject *v, PyObject *w, int op)
{
    PyObject *res;

    assert(Py_LT <= op && op <= Py_GE);
    if (v == NULL || w == NULL) { ... }
    if (Py_EnterRecursiveCall(" in comparison"))
        return NULL;
    res = do_richcompare(v, w, op);
    Py_LeaveRecursiveCall();
    return res;
}

กระบวนการPy_EnterRecursiveCall/ Py_LeaveRecursiveCallคำสั่งผสมไม่ได้อยู่ในเส้นทางก่อนหน้านี้ แต่เป็นมาโครที่ค่อนข้างรวดเร็วซึ่งจะลัดวงจรหลังจากการเพิ่มและลดบางส่วนของวงกลม

do_richcompare ทำ:

static PyObject *
do_richcompare(PyObject *v, PyObject *w, int op)
{
    richcmpfunc f;
    PyObject *res;
    int checked_reverse_op = 0;

    if (v->ob_type != w->ob_type && ...) { ... }
    if ((f = v->ob_type->tp_richcompare) != NULL) {
        res = (*f)(v, w, op);
        if (res != Py_NotImplemented)
            return res;
        ...
    }
    ...
}

นี้จะตรวจสอบอย่างรวดเร็วเพื่อโทรv->ob_type->tp_richcompareซึ่งเป็น

PyTypeObject PyUnicode_Type = {
    ...
    PyUnicode_RichCompare,      /* tp_richcompare */
    ...
};

ซึ่งทำ

PyObject *
PyUnicode_RichCompare(PyObject *left, PyObject *right, int op)
{
    int result;
    PyObject *v;

    if (!PyUnicode_Check(left) || !PyUnicode_Check(right))
        Py_RETURN_NOTIMPLEMENTED;

    if (PyUnicode_READY(left) == -1 ||
        PyUnicode_READY(right) == -1)
        return NULL;

    if (left == right) {
        switch (op) {
        case Py_EQ:
        case Py_LE:
        case Py_GE:
            /* a string is equal to itself */
            v = Py_True;
            break;
        case Py_NE:
        case Py_LT:
        case Py_GT:
            v = Py_False;
            break;
        default:
            ...
        }
    }
    else if (...) { ... }
    else { ...}
    Py_INCREF(v);
    return v;
}

ทางลัดนี้ใช้กับleft == right... แต่หลังจากทำเสร็จแล้ว

    if (!PyUnicode_Check(left) || !PyUnicode_Check(right))

    if (PyUnicode_READY(left) == -1 ||
        PyUnicode_READY(right) == -1)

ทั้งหมดในทุกเส้นทางนั้นมีลักษณะเช่นนี้ (inlining ด้วยตนเอง recursively, unrolling and pruning branch ที่รู้จักกันด้วยตนเอง)

POP()                           # Stack stuff
TOP()                           #
                                #
case PyCmp_IN:                  # Dispatch on operation
                                #
sqm != NULL                     # Dispatch to builtin op
sqm->sq_contains != NULL        #
*sqm->sq_contains               #
                                #
cmp == 0                        # Do comparison in loop
i < Py_SIZE(a)                  #
v == w                          #
op == Py_EQ                     #
++i                             # 
cmp == 0                        #
                                #
res < 0                         # Convert to Python-space
res ? Py_True : Py_False        #
Py_INCREF(v)                    #
                                #
Py_DECREF(left)                 # Stack stuff
Py_DECREF(right)                #
SET_TOP(res)                    #
res == NULL                     #
DISPATCH()                      #

VS

POP()                           # Stack stuff
TOP()                           #
                                #
default:                        # Dispatch on operation
                                #
Py_LT <= op                     # Checking operation
op <= Py_GE                     #
v == NULL                       #
w == NULL                       #
Py_EnterRecursiveCall(...)      # Recursive check
                                #
v->ob_type != w->ob_type        # More operation checks
f = v->ob_type->tp_richcompare  # Dispatch to builtin op
f != NULL                       #
                                #
!PyUnicode_Check(left)          # ...More checks
!PyUnicode_Check(right))        #
PyUnicode_READY(left) == -1     #
PyUnicode_READY(right) == -1    #
left == right                   # Finally, doing comparison
case Py_EQ:                     # Immediately short circuit
Py_INCREF(v);                   #
                                #
res != Py_NotImplemented        #
                                #
Py_LeaveRecursiveCall()         # Recursive check
                                #
Py_DECREF(left)                 # Stack stuff
Py_DECREF(right)                #
SET_TOP(res)                    #
res == NULL                     #
DISPATCH()                      #

ตอนนี้PyUnicode_CheckและPyUnicode_READYมันค่อนข้างถูกเพราะพวกเขาตรวจสอบเพียงสองสามฟิลด์ แต่มันควรจะชัดเจนว่าหนึ่งบนสุดเป็นพา ธ ของโค้ดที่เล็กกว่ามันมีการเรียกใช้ฟังก์ชันน้อยลงเพียงแค่หนึ่งคำสั่งสลับและเพียงเล็กน้อย

TL; DR:

ทั้งส่งไปยังif (left_pointer == right_pointer); ความแตกต่างคือพวกเขาทำงานให้ได้มากแค่ไหน inแค่ทำน้อยลง


18
นี่คือคำตอบที่เหลือเชื่อ ความสัมพันธ์ของคุณกับโครงการหลามคืออะไร?
kdbanman

9
@kdbanman ไม่มีจริงๆถึงแม้ว่าฉันจะสามารถบังคับวิธีการของฉันในบิต;)
Veedrac

21
@varepsilon Aww แต่ไม่มีใครสนใจที่จะอ่านโพสต์จริง ๆ ! ประเด็นของคำถามไม่ใช่คำตอบจริงๆ แต่เป็นกระบวนการที่ใช้เพื่อให้ได้คำตอบ - หวังว่าจะไม่มีคนจำนวนมากที่ใช้แฮ็คนี้ในการผลิต!
Veedrac

181

มีสามปัจจัยที่เล่นที่นี่ซึ่งรวมกันผลิตพฤติกรรมที่น่าแปลกใจนี้

ก่อน: inผู้ประกอบการใช้ทางลัดและตรวจสอบตัวตน ( x is y) ก่อนที่จะตรวจสอบความเท่าเทียมกัน ( x == y):

>>> n = float('nan')
>>> n in (n, )
True
>>> n == n
False
>>> n is n
True

ประการที่สอง: เพราะของสตริง ธ ฝึกงานทั้ง"x"ใน"x" in ("x", )จะเหมือนกัน:

>>> "x" is "x"
True

(คำเตือนใหญ่: นี่เป็นพฤติกรรมเฉพาะของการนำไปใช้งาน! ไม่isควรใช้เปรียบเทียบสตริงเพราะบางครั้งจะให้คำตอบที่น่าประหลาดใจตัวอย่างเช่น)"x" * 100 is "x" * 100 ==> False

ที่สาม: ตามรายละเอียดในคำตอบที่ยอดเยี่ยมของ Veedrac , tuple.__contains__( x in (y, )คือประมาณเทียบเท่า(y, ).__contains__(x)) ได้รับการจุดของการดำเนินการตรวจสอบตัวตนได้เร็วกว่าstr.__eq__(อีกครั้งx == yคือประมาณเทียบเท่าx.__eq__(y)) ไม่

คุณสามารถเห็นหลักฐานนี้x in (y, )ได้ช้ากว่าเหตุผลอย่างมีเหตุผลx == y:

In [18]: %timeit 'x' in ('x', )
10000000 loops, best of 3: 65.2 ns per loop

In [19]: %timeit 'x' == 'x'    
10000000 loops, best of 3: 68 ns per loop

In [20]: %timeit 'x' in ('y', ) 
10000000 loops, best of 3: 73.4 ns per loop

In [21]: %timeit 'x' == 'y'    
10000000 loops, best of 3: 56.2 ns per loop

x in (y, )กรณีช้าเพราะหลังจากที่isเปรียบเทียบล้มเหลวของinผู้ประกอบการอยู่กลับไปยังการตรวจสอบความเท่าเทียมกันตามปกติ (เช่นใช้==) ดังนั้นการเปรียบเทียบจะใช้เวลาประมาณจำนวนเดียวกันของเวลาที่==แสดงผลการดำเนินการทั้งหมดช้าลงเพราะค่าใช้จ่ายในการสร้าง tuple ที่ เดินสมาชิก ฯลฯ

ยังทราบว่าa in (b, )เป็นเพียงได้เร็วขึ้นเมื่อa is b:

In [48]: a = 1             

In [49]: b = 2

In [50]: %timeit a is a or a == a
10000000 loops, best of 3: 95.1 ns per loop

In [51]: %timeit a in (a, )      
10000000 loops, best of 3: 140 ns per loop

In [52]: %timeit a is b or a == b
10000000 loops, best of 3: 177 ns per loop

In [53]: %timeit a in (b, )      
10000000 loops, best of 3: 169 ns per loop

(ทำไมถึงa in (b, )เร็วกว่าa is b or a == bฉันเดาว่าคำสั่งเครื่องเสมือนของฉันจะมีน้อยลง -  a in (b, )มีเพียง ~ 3 คำสั่งเท่านั้นและa is b or a == bจะมีคำสั่ง VM อีกกี่ตัว)

Veedrac ของคำตอบ - https://stackoverflow.com/a/28889838/71522 - ไปในรายละเอียดมากขึ้นในเฉพาะสิ่งที่เกิดขึ้นในแต่ละช่วงเวลา==และinและมีมูลค่าการอ่าน


3
และเหตุผลที่มันไม่นี้มีแนวโน้มที่จะอนุญาตให้X in [X,Y,Z]ทำงานอย่างถูกต้องโดยไม่ต้องX, YหรือZมีการกำหนดวิธีการเท่าเทียมกัน (หรือมากกว่าความเสมอภาคเริ่มต้นคือisดังนั้นมันจะช่วยประหยัดไม่ต้องเรียก__eq__บนวัตถุที่ไม่มีผู้ใช้กำหนด__eq__และisเป็นจริงควรจะบ่งบอกถึงความคุ้มค่า -equality)
aruisdante

1
การใช้float('nan')อาจทำให้เข้าใจผิด มันเป็นคุณสมบัติของnanมันที่ไม่เท่ากับตัวมันเอง ที่อาจเปลี่ยนเวลา
dawg

@dawg ah, จุดดี - ตัวอย่างน่านมีไว้เพื่อแสดงให้เห็นถึงทางลัดที่inใช้ในการทดสอบการเป็นสมาชิก ฉันจะเปลี่ยนชื่อตัวแปรเพื่อชี้แจง
David Wolever

3
เท่าที่ฉันเข้าใจใน CPython 3.4.3 tuple.__contains__มีการใช้งานโดยการtuplecontainsโทรPyObject_RichCompareBoolและที่ส่งกลับทันทีในกรณีของตัวตน unicodeมีPyUnicode_RichCompareภายใต้ประทุนซึ่งมีทางลัดเหมือนกันสำหรับตัวตน
Cristian Ciupitu

3
ก็หมายความว่าไม่จำเป็นต้องไปได้"x" is "x" จะเป็นแต่จะไม่เร็วกว่านี้ True'x' in ('x', )True==
David Wolever
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.