Apakah nama variabel mempengaruhi kinerja situs web?


10

Apakah nama variabel mempengaruhi kinerja situs web? Saya tahu ini akan menjadi angka yang sangat rendah, tetapi masih ada yang bisa memberikan alasan untuk tidak memilih nama variabel panjang dalam aspek kinerja?


2
Harap jelaskan pertanyaan Anda - di mana variabel ini dan bahasa apa itu ditulis?
Luke Graham

16
Anda tidak boleh, PERNAH memilih nama variabel pendek dan tidak logis jika alasan Anda adalah kinerja (dipertanyakan). Kode sumber tersedia untuk dibaca orang lain, bukan untuk komputer yang memuaskan dan keuntungan kinerja mikroskopis mereka.
Michael JV

Saya menggunakan PHP ..
Avinash

2
... Dan Anda memiliki xpertdeveloper.com?
Jim G.

3
Hai Avinash dapatkah Anda menjelaskan dalam pertanyaan Anda alasan Anda untuk berpikir bahwa ini mungkin terjadi?

Jawaban:


17

adakah yang bisa memberikan alasan untuk tidak memilih nama variabel panjang dalam aspek kinerja?

Michael membahas jawabannya (yaitu Tidak) tetapi nama variabel memengaruhi kinerja programmer . Jika Anda membawa pengembang baru atau seseorang yang tidak terbiasa dengan kode, maka memiliki nama variabel yang panjang dan / atau membingungkan dapat mengganggu dan memperlambat proses pemahaman.

Secara umum, Anda ingin menggunakan nama variabel pendek dan deskriptif karena lebih mudah dibaca. Bayangkan jika Anda harus mengabaikan kode Anda selama 10 tahun dan kemudian mengerti semuanya lagi. Apakah Anda lebih suka membaca "getInput" atau "getInputFromUserWhoInputsStringOrElseInformReaderOfError"? (berlebihan tentu saja: P)

Namun, ada kalanya memiliki nama yang sedikit lebih panjang bisa bermanfaat. Misalnya, getBirthdayInput () akan jauh lebih deskriptif daripada getInput (). Anda ingin menyederhanakan suatu hal tetapi penyederhanaan yang berlebihan juga bisa menjadi masalah.


6
untuk membaca nama panjang lebih baik, jika Anda menemukan "getInputFromUserWhoInputsStringOrElseInformReaderOfError" Anda tidak perlu membaca dokumentasi apa fungsi ini, jika Anda menemukan "getInput" yang Anda butuhkan. Dan setelah 10 tahun, dokumentasi akan salah, atau tidak lengkap, atau hilang. getInputFromUserWhoInputsStringOrElseInformReaderOfError tentu terlalu lama, tetapi untuk memahami tentang apa itu lebih lama adalah lebih baik (dan saya tidak peduli bahwa wanita mengatakan ukuran itu tidak masalah).
Dainius

Saya tidak setuju dalam hal ini. Saya pikir hanya dengan membaca kode akan sangat mudah untuk memahami apa yang getInput () lakukan, terutama jika mencetak "input tidak valid" atau sesuatu setelahnya. Pasti ada saat-saat ketika nama yang lebih panjang bisa lebih baik - saya akan mengeditnya!
BlackJack

ofc itu tergantung dari konteks, tetapi dalam pengalaman saya nama yang lebih panjang lebih baik (tapi tidak selama getInputFromUserWhoInputsStringOrElseInformReaderOfError). Dan konteksnya sangat penting karena file.read () lebih cepat daripada file.readAllFileAsByteArray (). Tapi seperti yang saya katakan biasanya nama IMHO lagi memberikan informasi lebih lanjut.
Dainius

1
Jika dokumentasinya salah, tidak lengkap, atau hilang, basis kode itu akan gagal.
Christopher Mahan

2
Ini menjawab pertanyaan yang tidak ditanyakan.

16

Tidak, tidak akan. Secara umum, ketika kode dikompilasi, nama-nama variabel diganti dengan alamat memori yang dirujuk. Komputer tidak tahu apa-apa tentang nama variabel; mereka hanya ingin tahu di mana nilai disimpan.

Variabel adalah simbol, tidak lebih. Mereka mengganti nilai hex dengan nama sehingga programmer lebih mudah memahami apa yang mereka lakukan. Jadi, tidak akan ada peningkatan kinerja dengan memilih nama variabel yang lebih pendek.

Yang mengatakan, Anda mungkin mendapatkan perbaikan sangat kecil (dan saya berbicara mikroskopis) dalam waktu kompilasi dan interpretasi JIT pertama, tetapi itu hanya karena parser mengambil beberapa siklus CPU lebih sedikit untuk membaca nama variabel. Ini adalah biaya satu kali, dan secara statistik tidak signifikan ketika khawatir tentang kinerja.


11
Sementara jawaban Anda benar untuk pemrograman aplikasi, OP merujuk ke Situs web, dan karena itu ada kemungkinan dia menggunakan bahasa yang ditafsirkan. Dalam kasus seperti itu, kode harus dibaca dari file, lalu ditafsirkan. Dalam hal ini, nama variabel yang lebih panjang akan lebih lama untuk memuat & menguraikan Namun, peningkatan kinerja tidak akan signifikan, dan secara besar-besaran diimbangi oleh kerumitan tambahan bagi programmer untuk membaca dan memahami kode.
Gavin Coates

1
@ Gavin Benar untuk bahasa yang ditafsirkan juga - "JIT first interpretation". Sebagian besar bahasa yang ditafsirkan sekarang dikompilasi karena mereka mengeksekusi daripada eksekusi baris demi baris, AFAIK.
Michael K

1
Michael - untuk mengkompilasi, file pertama-tama harus dibaca ke dalam memori. Proses ini akan memakan waktu lebih lama tergantung pada panjang file. Nama variabel yang lebih panjang = file yang lebih panjang.
Gavin Coates

Pertanyaan ini ditandai sebagai PHP. PHP belum memiliki JIT - itu akan menjadi fitur baru dari rilis 8.0 yang direncanakan untuk akhir tahun ini. Itu mengkompilasi ke kode byte sebelum eksekusi, dan bytecode umumnya di-cache di webservers untuk digunakan dalam beberapa permintaan.
bdsl

8

Kecuali Anda menggunakan op-code cache (juga dikenal sebagai "akselerator PHP"), maka memang ada dampaknya. Tetapi dampaknya sangat rendah, sehingga bisa diabaikan. Jika Anda menggunakan op-code cache, maka tidak ada dampak.


1
dan jika Anda sangat peduli dengan kinerja sehingga Anda mempertimbangkan untuk memperpendek nama variabel untuk mendapatkan beberapa siklus, tidak menggunakan cache op-code akan menjadi kriminal ... dan direkomendasikan untuk beralih ke bahasa yang dikompilasi seperti C.
SF.

Tetapi jelas bahwa dampaknya akumulatif, jadi semakin besar aplikasinya, semakin besar dampaknya, bukan?
n00dles

Zend Opcache telah dikirimkan dengan PHP selama beberapa tahun sekarang, jadi semua orang harus menggunakannya. Saya pikir ini umumnya diaktifkan secara default.
bdsl

3

Meskipun Michael benar untuk pemrograman aplikasi, pertanyaan Anda mengacu pada pengembangan web dengan PHP, yang merupakan bahasa yang ditafsirkan. Dalam kasus seperti itu, kode harus dibaca dari file, lalu ditafsirkan. Dalam kasus ini, nama variabel yang lebih panjang akan membutuhkan waktu lebih lama untuk memuat & mem-parsing.

Namun kinerja yang dilakukan dengan melakukan itu tidak akan signifikan, dan mungkin akan berada di wilayah pecahan satu milidetik untuk keseluruhan skrip. Anda selalu dapat mencobanya dengan skrip sampel, dan menggunakan metode penghitungan waktu seperti yang dirinci di http://www.developerfusion.com/code/2058/determine-execution-time-in-php/ tetapi ini mungkin tidak akan mulai penghitungan waktu hingga setelah file dibaca. Selain itu, waktu eksekusi antar percobaan akan jauh lebih bervariasi daripada perbedaan antara panjang nama variabel, jadi Anda harus melakukan sejumlah percobaan yang signifikan dan mengambil rata-rata masing-masing sebelum Anda dapat memperoleh rata-rata jauh yang berarti.

Seperti yang ditunjukkan BlackJack, nama yang lebih panjang bisa jauh lebih sulit untuk dipahami, dan membutuhkan banyak upaya ekstra untuk mengetik (dan jauh lebih rentan terhadap kesalahan ketik). Meskipun mungkin ada sedikit peningkatan kinerja, ini tidak membenarkan kerumitan tambahan yang dibuat untuk programmer. Karena itu, nama-nama variabel pendek, ringkas, dan mudah dipahami lebih disukai.

Jadi singkatnya, jangan khawatir tentang nama panjang variabel, tetapi sebaliknya berkonsentrasi pada penulisan kode yang bersih dan bermakna.


1

Mungkin :

Kode server biasanya dikompilasi dan panjang nama variabel tidak akan memengaruhi karena alasan yang disebutkan. Namun, jika nama variabel digunakan untuk membangun markup berbagai operasi string. Karena respons HTTP (berisi markup / json yang dikembalikan / data yang dikembalikan) lebih besar, maka akan memakan waktu sedikit lebih lama, meskipun perbedaannya dapat diabaikan. Jika JavaScript tidak diperkecil, itu akan menjadi file yang lebih besar, membutuhkan waktu lebih lama untuk bepergian ke klien.

Selain mengecilkan file JavaScript, setiap upaya pengoptimalan untuk aplikasi web / situs web, akan lebih baik digunakan untuk aspek lain.


1

Ya, itu akan, tetapi tidak dalam arti yang Anda pikirkan.

Dengan nama variabel yang buruk, pengembang akan mudah bingung dalam kode sumber. Akan sulit dibaca dan sulit dimengerti.

Pada akhirnya, kode sumber akan sulit untuk dipelihara dan hampir tidak mungkin untuk membuatnya berkembang. Ini akan mengarah pada biaya pemeliharaan yang lebih tinggi, biaya pengembangan yang lebih tinggi, lebih banyak bug, dan kinerja yang lebih buruk .

Nama variabel tidak akan memiliki pengaruh sama sekali pada saat runtime, dan sama sekali diabaikan pada waktu kompilasi. Tetapi nama buruk pasti akan mengarah pada kinerja buruk karena tidak ada yang mengerti kode dan berakhir di tumpukan hack di atas yang lain, membuat segalanya semakin buruk setiap saat.

Baca ini untuk mengetahui tentang nama variabel yang baik: http://tottinge.blogsome.com/meaningfulnames

Perhatikan bahwa jika Anda merasa perlu nama variabel yang sangat panjang, itu berarti bahwa kode Anda tidak dirancang dengan baik. Nama variabel selalu dinyatakan dalam konteks: namespace, nama kelas, nama file, folder, nama fungsi, dll. Dengan demikian, jika nama harus panjang untuk eksplisit, ini berarti bahwa hal yang Anda coba beri nama DOESN ' T DIJUAL DI SINI . Dalam hal ini, pikirkan tentang menempatkan kode ini di tempat yang sesuai, atau buat tempat itu jika belum ada.


0

Jawabannya jelas ya, dalam hal php.

Jawaban yang mengatakan itu tidak akan membuat perbedaan belum tentu benar. Sebagai contoh, saya memiliki skrip php kecil, hanya beberapa baris, tetapi harus mengulang sekitar 1.950.000 kali sebelum menyelesaikan tugasnya, jadi meskipun satu skrip dijalankan mungkin tidak diperhatikan, pecahan detik tersebut bertambah secara substansial ketika berulang kali.


1
Tapi kamu salah. Setiap penerjemah php yang layak akan menguraikan kode hanya sekali. Orang-orang yang menulis penerjemah php tidak bodoh.
gnasher729

@ gnasher729 Anda membuat asumsi tentang bagaimana interpreter atau seluruh server bekerja dan Anda seharusnya tidak pernah melakukan itu. Bahkan jika itu hanya akan mem-parsing sekali per jalankan, itu dapat mem-parsing pada setiap proses dan tidak men-cache representasi yang di-parsing (sistem lain akan melakukan itu tetapi Anda tidak bisa tahu sebelumnya). Dan umumnya semakin banyak byte skrip, semakin lama waktu yang diperlukan untuk mem-parsing. Jadi Diorthotis tidak salah secara umum, ia hanya mungkin salah tentang sistem tertentu.
Mecki

0

Anda dapat menggunakan nama pendek yang membuat kode Anda lebih mudah dibaca. Anda akan menyimpan satu atau dua mikrodetik. Tetapi karena kodenya kurang mudah dibaca, lebih sulit untuk meningkatkan kodenya dan membuatnya lebih cepat. Jadi kode Anda yang tidak dapat dipelihara dan tidak dapat diperbaiki dengan nama pendek akan berakhir berjalan lebih lambat pada akhirnya.

Jadi, untuk menjawab pertanyaan Anda ("apakah itu memengaruhi kinerja"): Ya, tapi tidak sesuai keinginan Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.