ทำไมรหัสไพ ธ อนจึงทำงานได้เร็วขึ้นในฟังก์ชั่น?

def main():
    for i in xrange(10**8):
        pass
main()

รหัสชิ้นนี้ใน Python ทำงานใน (หมายเหตุ: การจับเวลาเสร็จสิ้นด้วยฟังก์ชั่นเวลาใน BASH ใน Linux)

real    0m1.841s
user    0m1.828s
sys     0m0.012s

อย่างไรก็ตามหาก for for ไม่ได้อยู่ในฟังก์ชัน

for i in xrange(10**8):
    pass

จากนั้นมันจะทำงานเป็นเวลานาน:

real    0m4.543s
user    0m4.524s
sys     0m0.012s

ทำไมนี้

คุณอาจถามว่าทำไมการเก็บตัวแปรภายในเครื่องให้รวดเร็วกว่า globals นี่เป็นรายละเอียดการติดตั้ง CPython

โปรดจำไว้ว่า CPython นั้นได้รับการคอมไพล์ด้วยไบต์โค้ดซึ่งล่ามทำงาน เมื่อฟังก์ชั่นถูกรวบรวมตัวแปรท้องถิ่นจะถูกเก็บไว้ในอาร์เรย์ขนาดคงที่ ( ไม่ใช่ a dict) และชื่อตัวแปรจะถูกกำหนดให้กับดัชนี สิ่งนี้เป็นไปได้เพราะคุณไม่สามารถเพิ่มตัวแปรท้องถิ่นลงในฟังก์ชันได้แบบไดนามิก จากนั้นการดึงตัวแปรท้องถิ่นเป็นการค้นหาตัวชี้ไปยังรายการและการเพิ่มจำนวน refcount PyObjectซึ่งเป็นเรื่องเล็กน้อย

เปรียบเทียบสิ่งนี้กับการค้นหาทั่วโลก ( LOAD_GLOBAL) ซึ่งเป็นการdictค้นหาจริงที่เกี่ยวข้องกับแฮชและอื่น ๆ นี่คือเหตุผลที่คุณต้องระบุglobal iว่าคุณต้องการให้เป็นโกลบอล: หากคุณเคยกำหนดให้กับตัวแปรภายในขอบเขตคอมไพเลอร์จะออกSTORE_FASTs สำหรับการเข้าถึงเว้นแต่คุณจะไม่บอก

อย่างไรก็ตามการค้นหาทั่วโลกยังคงได้รับการปรับให้เหมาะสม การค้นหาคุณสมบัติfoo.barนั้นเป็นสิ่งที่ช้ามาก!

นี่คือภาพประกอบเล็ก ๆเกี่ยวกับประสิทธิภาพของตัวแปรท้องถิ่น

ในฟังก์ชั่น bytecode คือ:

  2           0 SETUP_LOOP              20 (to 23)
              3 LOAD_GLOBAL              0 (xrange)
              6 LOAD_CONST               3 (100000000)
              9 CALL_FUNCTION            1
             12 GET_ITER            
        >>   13 FOR_ITER                 6 (to 22)
             16 STORE_FAST               0 (i)

  3          19 JUMP_ABSOLUTE           13
        >>   22 POP_BLOCK           
        >>   23 LOAD_CONST               0 (None)
             26 RETURN_VALUE        

ในระดับสูงสุด bytecode คือ:

  1           0 SETUP_LOOP              20 (to 23)
              3 LOAD_NAME                0 (xrange)
              6 LOAD_CONST               3 (100000000)
              9 CALL_FUNCTION            1
             12 GET_ITER            
        >>   13 FOR_ITER                 6 (to 22)
             16 STORE_NAME               1 (i)

  2          19 JUMP_ABSOLUTE           13
        >>   22 POP_BLOCK           
        >>   23 LOAD_CONST               2 (None)
             26 RETURN_VALUE        

ความแตกต่างก็คือว่าSTORE_FASTเร็ว (!) STORE_NAMEกว่า นี่เป็นเพราะในฟังก์ชั่นiเป็นท้องถิ่น แต่ที่ระดับบนสุดมันเป็นระดับโลก

เพื่อตรวจสอบ bytecode ใช้โมดูลdis ผมสามารถที่จะถอดแยกชิ้นส่วนฟังก์ชั่นโดยตรง แต่จะถอดรหัสระดับบนสุดที่ฉันมีที่จะใช้ในตัวcompile

นอกเหนือจากเวลาเก็บตัวแปรท้องถิ่น / ส่วนกลางการคาดการณ์ opcodeทำให้ฟังก์ชั่นเร็วขึ้น

ตามที่คำตอบอื่น ๆ อธิบายฟังก์ชั่นใช้STORE_FASTopcode ในลูป นี่คือโค้ดไบต์สำหรับการวนซ้ำของฟังก์ชัน:

    >>   13 FOR_ITER                 6 (to 22)   # get next value from iterator
         16 STORE_FAST               0 (x)       # set local variable
         19 JUMP_ABSOLUTE           13           # back to FOR_ITER

โดยปกติเมื่อมีการเรียกใช้โปรแกรม Python จะดำเนินการแต่ละ opcode ซึ่งกันและกันติดตามการทำงานของ stack และ preforming การตรวจสอบอื่น ๆ ใน stack frame หลังจากดำเนินการแต่ละ opcode การคาดการณ์ของ Opcode หมายความว่าในบางกรณี Python สามารถข้ามไปยัง opcode ถัดไปได้โดยตรงดังนั้นจึงไม่ควรใช้โอเวอร์เฮดนี้

ในกรณีนี้ทุกครั้งที่ Python เห็นFOR_ITER(ด้านบนของลูป) มันจะ "ทำนาย" ซึ่งSTORE_FASTเป็น opcode ถัดไปที่จะต้องดำเนินการ งูหลามแล้ว peeks ที่ opcode STORE_FASTต่อไปและหากการทำนายถูกต้องมันกระโดดตรงไปยัง นี่คือผลของการบีบสอง opcode เป็น opcode เดียว

ในทางตรงกันข้ามSTORE_NAMEopcode จะถูกใช้ในการวนซ้ำในระดับโลก Python ไม่ *ทำการคาดคะเนที่คล้ายกันเมื่อเห็น opcode นี้ แต่จะต้องกลับไปที่ด้านบนของลูปการประเมินผลซึ่งมีผลกระทบอย่างชัดเจนต่อความเร็วในการดำเนินการลูป

หากต้องการให้รายละเอียดทางเทคนิคเพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพนี้ต่อไปนี้เป็นคำกล่าวจากceval.cไฟล์ ("เอ็นจิ้น" ของเครื่องเสมือนของ Python):

opcodes บางตัวมีแนวโน้มที่จะมาเป็นคู่จึงทำให้สามารถทำนายรหัสที่สองเมื่อรันครั้งแรก ยกตัวอย่างเช่น มักจะตามมาด้วยGET_ITER FOR_ITERและFOR_ITERมักจะตามมาด้วยSTORE_FASTUNPACK_SEQUENCEหรือ

การตรวจสอบการคาดการณ์ทำให้เสียค่าใช้จ่ายในการทดสอบความเร็วสูงเดียวของตัวแปร register กับค่าคงที่ หากการจับคู่เป็นไปได้ดีการคาดคะเนสาขาภายในของโปรเซสเซอร์จะมีโอกาสสูงที่จะประสบความสำเร็จส่งผลให้เกิดการเปลี่ยนแปลงเกือบเป็นศูนย์เหนือ opcode ถัดไป การทำนายที่ประสบความสำเร็จจะช่วยประหยัดการเดินทางผ่านการวนรอบ eval รวมทั้งกิ่งไม้ที่ไม่สามารถคาดการณ์ได้สองแบบการHAS_ARGทดสอบและตัวเรือนสวิตช์ เมื่อรวมกับการทำนายสาขาภายในของตัวประมวลผลความสำเร็จPREDICTมีผลทำให้การใช้งานสอง opcode ราวกับว่าพวกมันเป็น opcode ใหม่เพียงครั้งเดียว

เราสามารถเห็นได้ในซอร์สโค้ดสำหรับFOR_ITERopcode ตรงกับที่การคาดการณ์STORE_FASTทำ:

case FOR_ITER:                         // the FOR_ITER opcode case
    v = TOP();
    x = (*v->ob_type->tp_iternext)(v); // x is the next value from iterator
    if (x != NULL) {                     
        PUSH(x);                       // put x on top of the stack
        PREDICT(STORE_FAST);           // predict STORE_FAST will follow - success!
        PREDICT(UNPACK_SEQUENCE);      // this and everything below is skipped
        continue;
    }
    // error-checking and more code for when the iterator ends normally                                     

PREDICTขยายตัวฟังก์ชั่นif (*next_instr == op) goto PRED_##opคือเราก็ข้ามไปยังจุดเริ่มต้นของ opcode ที่คาดการณ์ไว้ ในกรณีนี้เรากระโดดที่นี่:

PREDICTED_WITH_ARG(STORE_FAST);
case STORE_FAST:
    v = POP();                     // pop x back off the stack
    SETLOCAL(oparg, v);            // set it as the new local variable
    goto fast_next_opcode;

ตัวแปรโลคอลได้รับการตั้งค่าแล้วและ opcode ถัดไปจะพร้อมใช้งานสำหรับการดำเนินการ Python ดำเนินการต่อผ่าน iterable จนกว่าจะถึงจุดสิ้นสุดทำให้การทำนายผลสำเร็จทุกครั้ง

หน้าวิกิพีเดียหลามมีข้อมูลเพิ่มเติมเกี่ยวกับวิธีการ CPython ทำงานของเครื่องเสมือน