Saya rasa pengoptimuman prestasi menarik minat ramai pembangun kerana mereka mempelajari lebih lanjut tentang cara yang berbeza untuk menyelesaikan tugas. Beberapa suara dalaman bertanya, "Cara mana yang terbaik?" Walaupun terdapat banyak peralihan metrik untuk "terbaik", seperti JavaScript 2008 Douglas Crockford: The Good Parts, prestasi boleh diakses kerana kami boleh mengujinya sendiri.
Walau bagaimanapun, menguji dan membuktikan prestasi tidak selalunya mudah untuk diperbaiki.
Menjelang awal 2000-an, Internet Explorer telah memenangi perang pelayar pertama. IE ialah penyemak imbas lalai pada Mac untuk seketika. Netscape yang pernah dominan telah dijual kepada AOL dan akhirnya ditutup. Mozilla spin-off mereka berada dalam versi beta selama bertahun-tahun untuk penyemak imbas kendiri baharu mereka Phoenix Firebird Firefox.
Pada tahun 2003 Opera 7 keluar dengan Presto, enjin pemaparan baharu yang lebih pantas. Apple juga mengeluarkan Safari, pelayar berfokuskan prestasi untuk Mac yang dibina pada enjin Konqueror KHTML yang kurang dikenali. Firefox dilancarkan secara rasmi pada tahun 2004. Microsoft mengeluarkan IE 7 pada tahun 2006, dan Opera 9 mengeluarkan enjin JavaScript yang lebih pantas. 2007 membawa Safari pada kedua-dua Windows dan iPhone baharu. 2008 melihat Google Chrome dan penyemak imbas Android.
Dengan lebih banyak penyemak imbas dan lebih banyak platform, prestasi merupakan bahagian penting dalam tempoh ini. Versi penyemak imbas baharu kerap mengumumkan bahawa ia adalah penyemak imbas terpantas baharu. Penanda aras seperti SunSpider Apple dan Kraken Mozilla sering disebut dalam keluaran dan Google mengekalkan suite ujian Octane mereka sendiri. Pada tahun 2010, pasukan Chrome juga membuat satu siri percubaan "ujian kelajuan" untuk menunjukkan prestasi penyemak imbas.
Ujian Prestasi Mikro mendapat banyak perhatian pada tahun 2010-an. Web telah beralih daripada interaktiviti pada halaman terhad kepada Aplikasi Halaman Tunggal sebelah pelanggan penuh. Buku seperti JavaScript Prestasi Tinggi 2010 Nicholas Zakas menunjukkan bagaimana pilihan reka bentuk dan amalan pengekodan yang kelihatan kecil boleh memberi kesan prestasi yang bermakna.
Tidak lama kemudian, persaingan enjin JavaScript menangani beberapa kebimbangan prestasi utama ini dalam JavaScript Prestasi Tinggi, dan perubahan pantas dalam enjin menyukarkan untuk mengetahui apa yang terbaik sekarang. Dengan versi penyemak imbas baharu dan peranti mudah alih di sekeliling, ujian prestasi mikro menjadi topik hangat. Menjelang 2015, tapak ujian prestasi yang ditutup sekarang jsperf.com menjadi begitu popular sehingga mula mengalami masalah prestasinya sendiri disebabkan oleh spam.
Dengan enjin JavaScript yang berkembang, adalah mudah untuk menulis ujian, tetapi sukar untuk memastikan ujian anda adil malah sah. Jika ujian anda menggunakan banyak memori, ujian kemudian mungkin melihat kelewatan daripada pengumpulan sampah. Adakah masa persediaan dikira atau dikecualikan daripada semua ujian? Adakah ujian itu menghasilkan output yang sama? Adakah konteks ujian itu penting? Jika kami menguji !~arr.indexOf(val) vs arr.indexOf(val) === -1 adakah ia membuat perbezaan jika kami hanya menjalankan ungkapan atau menggunakannya dalam keadaan if?
Memandangkan jurubahasa skrip digantikan dengan pelbagai penyusun, kami mula melihat beberapa faedah — dan kesan sampingan — kod yang disusun: pengoptimuman. Kod berjalan dalam gelung yang tidak mempunyai kesan sampingan, contohnya, mungkin dioptimumkan sepenuhnya.
// Testing the speed of different comparison operators
for (let i = 0; i < 10000; i += 1) {
a === 10;
}
Oleh kerana ini menjalankan operasi 10000 kali tanpa keluaran atau kesan sampingan, pengoptimuman boleh membuangnya sepenuhnya. Namun, itu bukan jaminan.
Selain itu, pengoptimuman mikro boleh berubah dengan ketara dari keluaran ke keluaran. Penutupan malang jsperf.com bermakna berjuta-juta perbandingan ujian sejarah ke atas versi penyemak imbas yang berbeza telah hilang, tetapi ini masih boleh kita lihat hari ini dari semasa ke semasa.
Perlu diingat bahawa ujian prestasi pengoptimuman mikro disertakan dengan banyak kaveat.
Apabila peningkatan prestasi mula meningkat, kami melihat keputusan ujian melantun. Sebahagian daripada ini ialah peningkatan dalam enjin, tetapi kami juga melihat enjin mengoptimumkan kod untuk corak biasa. Walaupun penyelesaian berkod yang lebih baik wujud, terdapat manfaat sebenar kepada pengguna dalam mengoptimumkan corak kod biasa dan bukannya mengharapkan setiap tapak membuat perubahan.
Lebih teruk daripada prestasi penyemak imbas yang berubah-ubah, 2018 menyaksikan perubahan pada ketepatan dan ketepatan pemasa untuk mengurangkan serangan pelaksanaan spekulatif seperti Spectre dan Meltdown. Saya menulis artikel berasingan tentang isu masa ini, jika itu menarik minat anda.
Untuk merumitkan perkara, adakah anda menguji dan mengoptimumkan penyemak imbas terkini atau penyemak imbas yang paling rendah disokong projek anda? Begitu juga, apabila telefon pintar semakin popular, peranti pegang tangan dengan kuasa pemprosesan yang kurang ketara menjadi pertimbangan penting. Mengetahui tempat untuk memperuntukkan masa anda untuk hasil terbaik – atau hasil paling berkesan – menjadi lebih sukar.
Pengoptimuman pramatang ialah punca segala kejahatan.
-- Donald Knuth
Ini disebut dengan kerap. Orang menggunakannya untuk mencadangkan bahawa setiap kali kita berfikir tentang pengoptimuman, kita mungkin membuang masa dan memburukkan kod kita demi keuntungan khayalan atau tidak penting. Ini mungkin benar dalam banyak kes. Tetapi ada lagi petikan:
Kita harus melupakan kecekapan kecil, katakan kira-kira 97% masa: pengoptimuman pramatang adalah punca segala kejahatan. Namun kita tidak seharusnya melepaskan peluang kita dalam 3% kritikal itu.
Petikan yang lebih lengkap menambah konteks kritikal. Kita boleh menghabiskan banyak masa untuk kecekapan kecil jika kita membenarkan diri kita melakukannya. Ini selalunya mengambil masa daripada matlamat projek tanpa memberikan banyak nilai.
Saya secara peribadi menghabiskan banyak masa untuk pengoptimuman ini, dan pada masa ini ia tidak kelihatan seperti satu pembaziran. Tetapi jika difikirkan semula, tidak jelas berapa banyak kerja itu berbaloi. Saya pasti beberapa kod yang saya tulis ketika itu telah mencukur milisaat daripada masa pelaksanaan, tetapi saya tidak dapat benar-benar mengatakan jika masa yang disimpan itu penting.
Google malah bercakap tentang pulangan yang semakin berkurangan dalam persaraan 2017 mereka bagi suite ujian Octane. Saya amat mengesyorkan agar anda membaca siaran ini untuk mendapatkan gambaran yang baik tentang batasan dan masalah dalam pengoptimuman prestasi yang dialami oleh pasukan yang berdedikasi untuk kerja tersebut.
Jadi bagaimana kita hendak fokus pada "3% kritikal" itu?
Memahami cara dan masa kod digunakan membantu kami membuat keputusan yang lebih baik tentang tempat untuk fokus.
Tidak lama kemudian prestasi meningkat dan variasi penyemak imbas baharu mula menolak kami daripada jenis ujian mikro ini dan ke alat yang lebih luas seperti carta nyalaan.
Jika anda mempunyai 30 minit, saya mengesyorkan pembentangan Chrome DevSummit 2015 ini pada enjin V8. Ia bercakap tentang isu-isu ini dengan tepat... bahawa penyemak imbas terus berubah dan mengikuti butiran tersebut mungkin sukar.
Menggunakan pemantauan prestasi dan analisis aplikasi anda yang sedang berjalan boleh membantu anda mengenal pasti bahagian kod anda yang berjalan perlahan atau kerap berjalan dengan cepat. Ini meletakkan anda pada kedudukan yang baik untuk melihat pengoptimuman.
Menggunakan alat dan pustaka pemantauan prestasi membolehkan anda melihat cara kod berjalan dan bahagian mana yang perlu berfungsi. Mereka juga memberi kami peluang untuk melihat sama ada kawasan yang berbeza memerlukan kerja pada platform atau pelayar yang berbeza. Mungkin localStorage jauh lebih perlahan pada Chromebook dengan memori terhad dan storan eMMC. Mungkin anda perlu menyimpan lebih banyak maklumat untuk memerangi perkhidmatan selular yang perlahan atau berjerawat. Kita boleh meneka apa yang salah, tetapi mengukur ialah penyelesaian yang lebih baik.
Jika pangkalan pelanggan anda cukup besar, anda mungkin mendapat manfaat dalam alatan Pemantauan Pengguna Sebenar (RUM), yang berpotensi memberitahu anda bagaimana pengalaman pelanggan sebenar. Ini di luar skop artikel ini, tetapi saya telah menggunakannya di beberapa syarikat untuk memahami julat pengalaman pelanggan dan memfokuskan usaha pada prestasi dunia sebenar dan pengendalian ralat.
Memang mudah untuk menyelami "bagaimana saya menambah baik perkara ini", tetapi itu bukan jawapan yang terbaik. Anda mungkin menjimatkan banyak masa dengan berundur dan bertanya, "Adakah ini penyelesaian yang tepat untuk masalah ini?"
Masalah memuatkan senarai elemen yang sangat besar pada DOM? Mungkin senarai maya di mana hanya elemen yang boleh dilihat dimuatkan pada halaman akan menyelesaikan isu prestasi.
Melakukan banyak operasi yang kompleks pada pelanggan? Adakah lebih pantas untuk mengira sebahagian atau semua ini pada pelayan? Bolehkah sesetengah kerja dicache?
Mengambil langkah yang lebih besar ke belakang: Adakah ini antara muka pengguna yang sesuai untuk tugas ini? Jika anda mereka bentuk lungsur turun untuk menjangkakan dua puluh entri dan anda kini mempunyai tiga ribu, mungkin anda memerlukan komponen atau pengalaman yang berbeza untuk membuat pilihan.
Dengan mana-mana kerja persembahan, terdapat soalan sekunder "apa yang cukup"? Terdapat video hebat daripada Matt Parker dari Stand-up Maths bercakap tentang beberapa kod yang ditulisnya dan cara komunitinya memperbaiknya daripada minggu masa jalan kepada milisaat. Walaupun luar biasa bahawa pengoptimuman sedemikian boleh dilakukan, terdapat juga titik untuk hampir semua projek di mana anda mencapai "cukup baik".
Untuk program yang dijalankan sekali sahaja, minggu mungkin boleh diterima, jam kerja adalah lebih baik, tetapi berapa banyak masa yang anda luangkan untuk program itu dengan pantas menjadi pertimbangan penting.
Anda mungkin menganggapnya seperti toleransi dalam kejuruteraan. Kami mempunyai matlamat, dan kami mempunyai pelbagai penerimaan. Kita boleh menyasarkan yang sempurna sambil memahami bahawa kejayaan dan kesempurnaan tidak sama.
Matlamat adalah bahagian penting dalam pengoptimuman. Jika anda hanya tahu bahawa keadaan semasa adalah buruk, "jadikan ia lebih baik" ialah matlamat terbuka. Tanpa matlamat untuk perjalanan pengoptimuman anda, anda boleh membuang masa cuba mencari lebih banyak prestasi atau lebih pengoptimuman apabila anda boleh mengerjakan sesuatu yang lebih penting.
Saya tidak mempunyai metrik yang baik untuk ini kerana pengoptimuman prestasi boleh berbeza-beza, tetapi cuba untuk tidak tersesat dalam lalang. Ini benar-benar mengenai pengurusan projek dan perancangan lebih daripada penyelesaian pengekodan, tetapi input pembangun adalah penting semasa menentukan matlamat pengoptimuman. Seperti yang dicadangkan dalam bahagian Alternatif, pembaikan mungkin bukan "jadikan ini lebih pantas".
Dalam kes Matt Parker, dia memerlukan jawapan akhirnya, dan tidak perlu menggunakan peranti itu untuk perkara lain. Di dunia kita, kami sering mengukur prestasi pelawat dan kemungkinan kesan kewangannya lwn masa pembangun/pasukan dan kos peluang anda, jadi ukurannya tidak semudah itu.
Mari bayangkan kita tahu mengurangkan masa tambah ke troli sebanyak 50% akan meningkatkan pendapatan kita sebanyak 10%, tetapi ia akan mengambil masa dua bulan untuk menyiapkan kerja itu. Adakah terdapat sesuatu yang boleh memberi kesan kewangan yang lebih besar daripada kerja pengoptimuman dua bulan? Bolehkah anda mencapai beberapa manfaat dalam tempoh masa yang lebih singkat? Sekali lagi, ini adalah mengenai pengurusan projek daripada kod.
Apabila anda mendapati diri anda perlu mengoptimumkan kod, ini juga masa yang sesuai untuk melihat sama ada anda boleh mengasingkan kod itu daripada bahagian lain projek anda. Jika anda tahu anda perlu menulis pengoptimuman kompleks yang akan menyukarkan kod untuk diikuti, mengekstraknya ke utiliti atau pustaka boleh memudahkan penggunaan semula dan membolehkan anda mengemas kini pengoptimuman itu di satu tempat jika ia perlu berubah dari semasa ke semasa.
Prestasi ialah subjek yang rumit dengan banyak kelainan. Jika anda tidak berhati-hati, anda boleh menggunakan banyak tenaga untuk keuntungan praktikal yang sangat sedikit. Rasa ingin tahu boleh menjadi guru yang baik, tetapi ia tidak selalu mencapai hasil. Terdapat faedah untuk bermain dengan prestasi kod, tetapi juga masa untuk menganalisis sumber kelambatan sebenar dalam projek anda dan menggunakan alatan yang tersedia untuk membantu menyelesaikannya.
Atas ialah kandungan terperinci Ujian Prestasi Mikro JavaScript, Sejarah dan Had. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Cara menggunakan fungsi vlookup
cip
Kod yang biasa digunakan dalam bahasa html
Bagaimana untuk memasukkan pemacu d dengan cmd
Bagaimana untuk mendayakan perkhidmatan log masuk sekunder
Windows 11 pemindahan komputer saya ke tutorial desktop
Apakah pemalam yang diperlukan untuk vscode menjalankan HTML?
Perisian untuk membuat penyelesai Sudoku
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
