Tại sao mã Python chạy nhanh hơn trong một hàm?

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

Đoạn mã này trong Python chạy trong (Lưu ý: Thời gian được thực hiện với hàm thời gian trong BASH trong Linux.)

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

Tuy nhiên, nếu vòng lặp for không được đặt trong một hàm,

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

sau đó nó chạy trong một thời gian dài hơn nhiều:

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

Tại sao lại thế này?

Bạn có thể hỏi tại sao lưu trữ các biến cục bộ nhanh hơn so với toàn cầu. Đây là một chi tiết thực hiện CPython.

Hãy nhớ rằng CPython được biên dịch thành mã byte, trình thông dịch chạy. Khi một hàm được biên dịch, các biến cục bộ được lưu trữ trong một mảng có kích thước cố định ( không phải a dict) và các tên biến được gán cho các chỉ mục. Điều này là có thể bởi vì bạn không thể tự động thêm các biến cục bộ vào một hàm. Sau đó, lấy một biến cục bộ theo nghĩa đen là một con trỏ tra cứu vào danh sách và tăng số đếm trên PyObjectđó là tầm thường.

Tương phản điều này với một tra cứu toàn cầu ( LOAD_GLOBAL), đó là một dicttìm kiếm thực sự liên quan đến hàm băm và vân vân. Ngẫu nhiên, đây là lý do tại sao bạn cần chỉ định global inếu bạn muốn nó là toàn cục: nếu bạn đã gán cho một biến trong phạm vi, trình biên dịch sẽ cấp STORE_FASTs cho quyền truy cập của nó trừ khi bạn không nói cho nó biết.

Nhân tiện, tra cứu toàn cầu vẫn được tối ưu hóa khá. Tra cứu thuộc tính foo.barlà những người thực sự chậm!

Dưới đây là minh họa nhỏ về hiệu quả biến cục bộ.

Bên trong một hàm, mã byte là:

  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        

Ở cấp độ cao nhất, mã byte là:

  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        

Sự khác biệt là STORE_FASTnhanh hơn (!) So với STORE_NAME. Điều này là bởi vì trong một chức năng, ilà một địa phương nhưng tại toplevel nó là một toàn cầu.

Để kiểm tra mã byte, sử dụng dismô-đun . Tôi đã có thể tháo rời hàm trực tiếp, nhưng để tháo rời mã toplevel tôi phải sử dụng compilenội dung .

Ngoài thời gian lưu trữ biến cục bộ / toàn cầu, dự đoán opcode làm cho chức năng nhanh hơn.

Như các câu trả lời khác giải thích, hàm sử dụng STORE_FASTopcode trong vòng lặp. Đây là mã byte cho vòng lặp của hàm:

    >>   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

Thông thường khi một chương trình được chạy, Python thực thi lần lượt từng opcode, theo dõi ngăn xếp và tạo ra các kiểm tra khác trên khung ngăn xếp sau khi mỗi opcode được thực thi. Dự đoán Opcode có nghĩa là trong một số trường hợp, Python có thể nhảy trực tiếp sang opcode tiếp theo, do đó tránh được một số chi phí này.

Trong trường hợp này, mỗi khi Python nhìn thấy FOR_ITER(đỉnh của vòng lặp), nó sẽ "dự đoán" đó STORE_FASTlà opcode tiếp theo mà nó phải thực thi. Python sau đó nhìn trộm mã op tiếp theo và, nếu dự đoán là chính xác, nó sẽ nhảy thẳng vào STORE_FAST. Điều này có tác dụng ép hai opcode thành một opcode duy nhất.

Mặt khác, STORE_NAMEopcode được sử dụng trong vòng lặp ở cấp độ toàn cầu. Python không * không * đưa ra dự đoán tương tự khi nhìn thấy opcode này. Thay vào đó, nó phải quay trở lại đầu vòng lặp đánh giá có ý nghĩa rõ ràng đối với tốc độ thực hiện vòng lặp.

Để cung cấp thêm một số chi tiết kỹ thuật về tối ưu hóa này, đây là trích dẫn từ ceval.ctệp ("công cụ" của máy ảo Python):

Một số opcode có xu hướng đi theo cặp do đó có thể dự đoán mã thứ hai khi mã đầu tiên được chạy. Ví dụ, GET_ITERthường được theo sau bởi FOR_ITER. Và FOR_ITERthường được theo sau bởiSTORE_FAST hoặc UNPACK_SEQUENCE.

Việc xác minh dự đoán sẽ tốn một thử nghiệm tốc độ cao duy nhất của biến đăng ký so với hằng số. Nếu việc ghép nối là tốt, thì việc xác định nhánh bên trong của bộ xử lý có khả năng thành công cao, dẫn đến việc chuyển đổi gần như bằng không sang opcode tiếp theo. Một dự đoán thành công tiết kiệm một chuyến đi thông qua vòng lặp eval bao gồm hai nhánh không thể đoán trước của nó, HAS_ARGthử nghiệm và trường hợp chuyển đổi. Kết hợp với dự đoán nhánh bên trong của bộ xử lý, một thành công PREDICTcó tác dụng làm cho hai opcode chạy như thể chúng là một opcode mới duy nhất với các phần thân được kết hợp.

Chúng ta có thể thấy trong mã nguồn cho FOR_ITERopcode chính xác nơi dự đoán STORE_FASTđược thực hiện:

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                                     

Các PREDICTchức năng mở rộng để if (*next_instr == op) goto PRED_##optức là chúng ta chỉ cần nhảy đến sự bắt đầu của opcode dự đoán. Trong trường hợp này, chúng tôi nhảy vào đây:

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;

Biến cục bộ hiện được đặt và opcode tiếp theo sẽ được thực thi. Python tiếp tục lặp đi lặp lại cho đến khi nó kết thúc, đưa ra dự đoán thành công mỗi lần.

Các trang wiki Python có thêm thông tin về làm thế nào máy ảo CPython của hoạt động.