Apakah "x <y <z" lebih cepat dari "x <y dan y <z"?

Dari halaman ini , kita tahu bahwa:

Perbandingan berantai lebih cepat daripada menggunakan andoperator. Tulis x < y < zalih-alih x < y and y < z.

Namun, saya mendapat hasil berbeda menguji cuplikan kode berikut:

$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.8" "x < y < z"
1000000 loops, best of 3: 0.322 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.8" "x < y and y < z"
1000000 loops, best of 3: 0.22 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.1" "x < y < z"
1000000 loops, best of 3: 0.279 usec per loop
$ python -m timeit "x = 1.2" "y = 1.3" "z = 1.1" "x < y and y < z"
1000000 loops, best of 3: 0.215 usec per loop

Sepertinya itu x < y and y < zlebih cepat daripada x < y < z. Mengapa?

Setelah mencari beberapa posting di situs ini (seperti ini ) saya tahu bahwa "dievaluasi hanya sekali" adalah kuncinya x < y < z, namun saya masih bingung. Untuk melakukan studi lebih lanjut, saya membongkar dua fungsi ini menggunakan dis.dis:

import dis

def chained_compare():
        x = 1.2
        y = 1.3
        z = 1.1
        x < y < z

def and_compare():
        x = 1.2
        y = 1.3
        z = 1.1
        x < y and y < z

dis.dis(chained_compare)
dis.dis(and_compare)

Dan hasilnya adalah:

## chained_compare ##

  4           0 LOAD_CONST               1 (1.2)
              3 STORE_FAST               0 (x)

  5           6 LOAD_CONST               2 (1.3)
              9 STORE_FAST               1 (y)

  6          12 LOAD_CONST               3 (1.1)
             15 STORE_FAST               2 (z)

  7          18 LOAD_FAST                0 (x)
             21 LOAD_FAST                1 (y)
             24 DUP_TOP
             25 ROT_THREE
             26 COMPARE_OP               0 (<)
             29 JUMP_IF_FALSE_OR_POP    41
             32 LOAD_FAST                2 (z)
             35 COMPARE_OP               0 (<)
             38 JUMP_FORWARD             2 (to 43)
        >>   41 ROT_TWO
             42 POP_TOP
        >>   43 POP_TOP
             44 LOAD_CONST               0 (None)
             47 RETURN_VALUE

## and_compare ##

 10           0 LOAD_CONST               1 (1.2)
              3 STORE_FAST               0 (x)

 11           6 LOAD_CONST               2 (1.3)
              9 STORE_FAST               1 (y)

 12          12 LOAD_CONST               3 (1.1)
             15 STORE_FAST               2 (z)

 13          18 LOAD_FAST                0 (x)
             21 LOAD_FAST                1 (y)
             24 COMPARE_OP               0 (<)
             27 JUMP_IF_FALSE_OR_POP    39
             30 LOAD_FAST                1 (y)
             33 LOAD_FAST                2 (z)
             36 COMPARE_OP               0 (<)
        >>   39 POP_TOP
             40 LOAD_CONST               0 (None)

Tampaknya perintah itu x < y and y < zmemiliki lebih sedikit perbedaan daripada x < y < z. Haruskah saya mempertimbangkan x < y and y < zlebih cepat daripada x < y < z?

Diuji dengan Python 2.7.6 pada CPU Intel (R) Xeon (R) E5640 @ 2.67GHz.

Perbedaannya adalah bahwa x < y < z yhanya dievaluasi sekali. Ini tidak membuat perbedaan besar jika y adalah variabel, tetapi itu terjadi ketika itu adalah panggilan fungsi, yang membutuhkan waktu untuk menghitung.

from time import sleep
def y():
    sleep(.2)
    return 1.3
%timeit 1.2 < y() < 1.8
10 loops, best of 3: 203 ms per loop
%timeit 1.2 < y() and y() < 1.8
1 loops, best of 3: 405 ms per loop

Bytecode optimal untuk kedua fungsi yang Anda tetapkan adalah

          0 LOAD_CONST               0 (None)
          3 RETURN_VALUE

karena hasil perbandingan tidak digunakan. Mari kita buat situasi lebih menarik dengan mengembalikan hasil perbandingan. Mari juga hasilnya tidak diketahui pada waktu kompilasi.

def interesting_compare(y):
    x = 1.1
    z = 1.3
    return x < y < z  # or: x < y and y < z

Sekali lagi, dua versi perbandingan secara semantik identik, sehingga bytecode optimal adalah sama untuk kedua konstruksi. Sebisa mungkin aku bisa menyelesaikannya, akan terlihat seperti ini. Saya telah membubuhi keterangan setiap baris dengan konten stack sebelum dan sesudah setiap opcode, dalam Forth notation (atas stack di kanan, --membagi sebelum dan sesudah, trailing ?menunjukkan sesuatu yang mungkin ada atau tidak ada di sana). Perhatikan bahwa RETURN_VALUEbuang semua yang terjadi pada tumpukan di bawah nilai yang dikembalikan.

          0 LOAD_FAST                0 (y)    ;          -- y
          3 DUP_TOP                           ; y        -- y y
          4 LOAD_CONST               0 (1.1)  ; y y      -- y y 1.1
          7 COMPARE_OP               4 (>)    ; y y 1.1  -- y pred
         10 JUMP_IF_FALSE_OR_POP     19       ; y pred   -- y
         13 LOAD_CONST               1 (1.3)  ; y        -- y 1.3
         16 COMPARE_OP               0 (<)    ; y 1.3    -- pred
     >>  19 RETURN_VALUE                      ; y? pred  --

Jika implementasi bahasa, CPython, PyPy, apa pun, tidak menghasilkan bytecode ini (atau urutan operasinya yang setara) untuk kedua variasi, yang menunjukkan kualitas buruk kompiler bytecode itu . Mendapatkan dari urutan bytecode yang Anda posting di atas adalah masalah yang terpecahkan (saya pikir semua yang Anda butuhkan untuk kasus ini adalah pelipatan konstan , penghilangan kode mati , dan pemodelan yang lebih baik dari isi tumpukan; penghapusan subekspresi umum juga akan murah dan berharga ), dan benar-benar tidak ada alasan untuk tidak melakukannya dalam implementasi bahasa modern.

Sekarang, semua implementasi bahasa saat ini memiliki kompiler bytecode berkualitas rendah. Tetapi Anda harus mengabaikannya saat melakukan pengkodean! Anggap kompiler bytecode itu bagus, dan tulis kode yang paling mudah dibaca . Mungkin akan cukup cepat. Jika tidak, cari peningkatan algoritmik terlebih dahulu, dan coba Cython kedua - yang akan memberikan peningkatan lebih banyak untuk upaya yang sama daripada tweak tingkat ekspresi apa pun yang mungkin Anda terapkan.

Karena perbedaan dalam output tampaknya karena kurangnya optimasi, saya pikir Anda harus mengabaikan perbedaan itu untuk kebanyakan kasus - bisa jadi perbedaannya akan hilang. Perbedaannya adalah karena yhanya harus dievaluasi sekali dan itu diselesaikan dengan menduplikasi pada tumpukan yang membutuhkan tambahan POP_TOP- solusi untuk menggunakan LOAD_FASTmungkin dapat dilakukan.

Namun perbedaan yang penting adalah bahwa pada x<y and y<zyang kedua yharus dievaluasi dua kali jika x<ydievaluasi benar, ini memiliki implikasi jika evaluasi ymemakan waktu yang cukup lama atau memiliki efek samping.

Dalam sebagian besar skenario Anda harus menggunakan x<y<zmeskipun itu agak lambat.

Pertama-tama, perbandingan Anda tidak banyak berarti karena dua konstruksi yang berbeda tidak diperkenalkan untuk memberikan peningkatan kinerja, jadi Anda tidak boleh memutuskan apakah akan menggunakan satu di tempat yang lain berdasarkan itu.

The x < y < zmembangun:

1. Lebih jelas dan lebih langsung dalam artinya.
2. Semantiknya adalah apa yang Anda harapkan dari "makna matematika" dari perbandingan: evalute x, ydan z sekali dan periksa apakah seluruh kondisi berlaku. Menggunakan andperubahan semantik dengan mengevaluasi ybeberapa kali, yang dapat mengubah hasilnya .

Jadi pilih satu di tempat yang lain tergantung pada semantik yang Anda inginkan dan, jika mereka setara, apakah satu lebih mudah dibaca daripada yang lain.

Ini mengatakan: lebih banyak kode yang dibongkar tidak menyiratkan kode lebih lambat. Namun mengeksekusi lebih banyak operasi bytecode berarti bahwa setiap operasi lebih sederhana dan membutuhkan iterasi dari loop utama. Ini berarti bahwa jika operasi yang Anda lakukan sangat cepat (misalnya pencarian variabel lokal seperti yang Anda lakukan di sana), maka overhead untuk mengeksekusi lebih banyak operasi bytecode bisa jadi masalah.

Tetapi perhatikan bahwa hasil ini tidak berlaku dalam situasi yang lebih umum, hanya pada "kasus terburuk" yang terjadi pada profil Anda. Seperti yang dicatat orang lain, jika Anda berubahy sesuatu yang membutuhkan waktu sedikit lebih lama, Anda akan melihat bahwa hasilnya berubah, karena notasi berantai mengevaluasinya hanya sekali.

Meringkas:

• Pertimbangkan semantik sebelum pertunjukan.
• Mempertimbangkan keterbacaan akun.
• Jangan percaya tolok ukur mikro. Selalu profil dengan berbagai jenis parameter untuk melihat bagaimana waktu fungsi / ekspresi berperilaku dalam kaitannya dengan parameter tersebut dan pertimbangkan bagaimana Anda berencana untuk menggunakannya.