Kapan lebih baik mengoptimalkan perangkat lunak untuk kinerja yang lebih baik, di awal atau di akhir pengembangan?

Saya seorang pengembang perangkat lunak junior dan saya bertanya-tanya kapan akan menjadi waktu terbaik untuk mengoptimalkan perangkat lunak untuk kinerja (kecepatan) yang lebih baik.

Dengan asumsi perangkat lunak tidak terlalu besar dan rumit untuk dikelola, apakah lebih baik menghabiskan lebih banyak waktu di awal untuk mengoptimalkannya atau haruskah saya mengembangkan perangkat lunak yang menjalankan semua fungsi dengan benar dan kemudian melanjutkan untuk mengoptimalkannya untuk kinerja yang lebih baik?

Hal nomor satu harus selalu dan selamanya dapat dibaca. Jika lambat tapi mudah dibaca, saya bisa memperbaikinya. Jika rusak tetapi dapat dibaca, saya bisa memperbaikinya. Jika tidak dapat dibaca, saya harus bertanya kepada orang lain apa yang seharusnya dilakukan.

Sungguh luar biasa bagaimana performant kode Anda bisa ketika Anda hanya fokus agar dapat dibaca. Sedemikian rupa sehingga saya biasanya mengabaikan kinerja sampai diberi alasan untuk peduli. Itu seharusnya tidak berarti bahwa saya tidak peduli dengan kecepatan. Saya lakukan. Saya baru saja menemukan bahwa ada beberapa masalah yang solusinya sebenarnya lebih cepat ketika dibuat sulit untuk dibaca.

Hanya dua hal yang membuat saya keluar dari mode ini:

1. Ketika saya melihat peluang pada peningkatan O besar yang besar , itupun hanya ketika n cukup besar sehingga siapa pun akan peduli.
2. Ketika saya memiliki tes yang menunjukkan masalah kinerja nyata. Bahkan dengan pengalaman puluhan tahun saya masih mempercayai tes lebih dari matematika saya. Dan saya pandai matematika.

Bagaimanapun, hindari kelumpuhan analisis dengan membuat diri Anda berpikir Anda tidak boleh mencoba solusi karena itu mungkin bukan yang tercepat. Kode Anda sebenarnya akan bermanfaat jika Anda mencoba beberapa solusi karena membuat perubahan akan memaksa Anda untuk menggunakan desain yang membuatnya mudah untuk diubah. Basis kode yang fleksibel dapat dibuat lebih cepat nanti di tempat yang sangat membutuhkannya. Pilih fleksibel daripada kecepatan dan Anda dapat memilih kecepatan yang Anda butuhkan.

Jika tingkat kinerja tertentu diperlukan (persyaratan non-fungsional), maka itu harus menjadi tujuan desain sejak awal. Misalnya ini dapat memengaruhi teknologi mana yang mungkin sesuai, atau bagaimana Anda menyusun aliran data dalam program.

Tetapi secara umum, tidak mungkin untuk mengoptimalkan sebelum kode ditulis: pertama membuatnya bekerja, kemudian membuatnya benar, dan akhirnya membuatnya cepat .

Satu masalah besar dengan mengoptimalkan sebelum menerapkan sebagian besar fungsi adalah bahwa Anda telah mengunci diri Anda dalam keputusan desain yang kurang optimal di tempat yang salah. Seringkali (tetapi tidak harus) tradeoff antara rawatan dan kinerja. Sebagian besar program Anda sama sekali tidak relevan untuk kinerja! Program tipikal hanya memiliki beberapa hot spot yang benar-benar layak dioptimalkan. Jadi mengorbankan pemeliharaan untuk kinerja di semua tempat yang tidak membutuhkan kinerja adalah perdagangan yang sangat buruk.

Mengoptimalkan untuk pemeliharaan adalah pendekatan yang lebih baik. Jika Anda menghabiskan kepintaran Anda pada pemeliharaan dan desain yang jelas, Anda akan menemukan lebih mudah dalam jangka panjang untuk mengidentifikasi bagian-bagian penting, dan mengoptimalkannya dengan aman tanpa mengorbankan keseluruhan desain.

kapan akan menjadi waktu terbaik untuk mengoptimalkan perangkat lunak untuk kinerja (kecepatan) yang lebih baik.

Mulailah dengan menghilangkan dari pikiran Anda konsep bahwa kinerja adalah hal yang sama dengan kecepatan. Kinerja adalah apa yang diyakini pengguna sebagai kinerja .

Jika Anda membuat aplikasi merespons dua kali lebih cepat dari klik mouse dan Anda beralih dari sepuluh mikrodetik menjadi lima mikrodetik, pengguna tidak peduli. Jika Anda membuat aplikasi merespons dua kali lebih cepat dari klik mouse dan Anda beralih dari empat ribu tahun menjadi dua ribu tahun, sekali lagi, pengguna tidak peduli.

Jika Anda membuat aplikasi Anda dua kali lebih cepat dan Anda menggunakan semua memori pada mesin dan crash, pengguna tidak peduli bahwa itu sekarang dua kali lebih cepat.

Kinerja adalah ilmu membuat pengorbanan yang efektif tentang konsumsi sumber daya untuk mencapai pengalaman pengguna tertentu. Waktu pengguna adalah sumber daya penting , tetapi tidak pernah hanya tentang "lebih cepat". Mencapai tujuan kinerja hampir selalu membutuhkan pengorbanan, dan mereka sering bertukar waktu untuk ruang atau sebaliknya.

Dengan asumsi perangkat lunak tidak terlalu besar dan rumit untuk dikelola

Itu asumsi yang mengerikan.

Jika perangkat lunak tidak besar dan rumit untuk dikelola maka mungkin tidak menyelesaikan masalah menarik yang dipedulikan pengguna, dan mungkin super mudah dioptimalkan.

apakah lebih baik menghabiskan lebih banyak waktu di awal untuk mengoptimalkannya atau haruskah saya mengembangkan perangkat lunak yang menjalankan semua fungsi dengan benar dan kemudian melanjutkan untuk mengoptimalkannya untuk kinerja yang lebih baik?

Anda duduk di sana di halaman kosong dan Anda menulis. void main() {}Apakah Anda mulai mengoptimalkan? Tidak ada yang dioptimalkan! Urutan yang benar adalah:

• Buat kompilasi
• Jadikan itu benar
• Jadikan elegan
• Buat itu cepat

Jika Anda mencoba melakukannya dengan urutan lain Anda berakhir dengan kode yang salah yang berantakan, dan sekarang Anda punya program yang menghasilkan jawaban yang salah dengan sangat cepat dan menolak perubahan.

Tapi ada langkah yang hilang di sana. Urutan benar yang sebenarnya adalah:

• Bekerja dengan pelanggan dan manajemen untuk menetapkan metrik dan sasaran kinerja yang realistis dan dapat diukur, mengingat kecepatan bukan satu-satunya metrik yang diperhatikan pelanggan.
• Terapkan alat uji yang dapat melacak kondisi proyek saat ini terhadap sasaran Anda
• Buat kompilasi
• Jalankan tes. Jika Anda tidak lagi dalam sasaran Anda, sadarilah bahwa Anda mungkin telah menempuh jalan yang buruk lebih awal. Gunakan sains . Apakah Anda memperkenalkan algoritme buruk yang dapat diperbaiki, atau ada sesuatu yang secara fundamental salah? Jika secara fundamental salah, maka mulailah dari awal. Jika itu bisa diperbaiki, masukkan bug dan kembali lagi nanti.
• Jadikan itu benar
• Jalankan tes lagi ...
• Jadikan elegan
• Jalankan tes lagi ...
• Apakah Anda mematuhi tujuan Anda? Jika ya, pergilah ke pantai . Jika tidak, buatlah dengan cukup cepat .

Sebagai aturan umum, yang terbaik adalah mengoptimalkan kinerja nanti, tetapi saya telah melihat banyak proyek memburuk ketika pengembang menyadari bahwa mereka berakhir dengan perangkat lunak yang melambat ketika ada beban atau data signifikan ditambahkan ke dalamnya.

Jadi, pendekatan jalan tengah akan menjadi yang terbaik menurut saya; jangan terlalu menekankan hal itu, tetapi jangan mengabaikan kinerja sama sekali.

Saya akan memberikan contoh yang telah saya lihat berkali-kali; diberikan perpustakaan ORM, kami memiliki entitas Pengguna yang dapat memiliki satu atau lebih Pesanan. Mari kita lingkarkan semua Pesanan untuk Pengguna, dan cari tahu berapa banyak yang telah dihabiskan Pengguna di toko kami - pendekatan naif:

User user = getUser();
int totalAmount;
for (Order o : user.getOrders()) {
  totalAmount += o.getTotalAmount();
} 

Saya telah melihat pengembang menulis hal serupa, tanpa memikirkan implikasinya; pertama kita mendapatkan pengguna, yang semoga hanya akan menjadi satu permintaan SQL di tabel Pengguna (tapi mungkin melibatkan lebih banyak, lebih banyak), kemudian kita mengulangi pesanan, yang mungkin termasuk mendapatkan semua data yang relevan untuk semua baris pesanan pada pesanan , informasi produk, dll. - semua ini hanya untuk mendapatkan satu bilangan bulat untuk setiap pesanan!

Jumlah pertanyaan SQL di sini mungkin mengejutkan Anda. Tentu saja, ini tergantung pada bagaimana struktur entitas Anda.

Di sini, pendekatan yang benar kemungkinan besar akan menambahkan fungsi terpisah untuk mendapatkan jumlah dari basis data melalui kueri terpisah yang ditulis dalam bahasa kueri yang disediakan oleh ORM, dan saya akan menganjurkan melakukan ini pertama kali , dan tidak menunda ini untuk nanti; karena jika Anda melakukannya, Anda mungkin akan berakhir dengan lebih banyak masalah untuk diurus, dan tidak yakin harus mulai dari mana.

Kinerja sistem total adalah produk dari interaksi kompleks dari totalitas komponen sistem. Ini adalah sistem nonlinier. Oleh karena itu kinerja akan terjaga keamanannya tidak hanya oleh kinerja individu komponen 'tetapi oleh kemacetan di antara mereka.

Jelas Anda tidak dapat menguji kemacetan jika semua komponen sistem Anda belum dibangun, jadi Anda tidak dapat benar-benar menguji dengan sangat baik sejak awal. Di sisi lain, setelah sistem dibangun, Anda mungkin tidak merasa begitu mudah untuk melakukan perubahan yang Anda perlu lakukan untuk mendapatkan kinerja yang Anda inginkan. Jadi ini adalah Catch-22 bone fide .

Untuk membuat masalah lebih sulit, profil kinerja Anda dapat berubah secara drastis ketika Anda beralih ke lingkungan seperti produksi, yang seringkali tidak tersedia sejak dini.

Jadi apa yang kamu lakukan? Nah, beberapa hal.

1. Bersikap pragmatis. Sejak awal, Anda dapat memilih untuk menggunakan fitur platform yang merupakan "praktik terbaik" untuk kinerja; misalnya, gunakan penyatuan koneksi, transaksi asinkron, dan menghindari status penuh, yang bisa menjadi kematian aplikasi multi-utas di mana pekerja yang berbeda bersaing untuk akses ke data bersama. Biasanya Anda tidak akan menguji pola ini untuk kinerja, Anda hanya akan tahu dari pengalaman apa yang bekerja dengan baik.

2. Berulang-ulang. Mengambil langkah-langkah kinerja awal ketika sistem ini relatif baru, dan tes ulang sesekali untuk memastikan kode yang baru diperkenalkan tidak menurunkan kinerja terlalu banyak.

3. Jangan optimisasi lebih awal. Anda tidak pernah tahu apa yang akan menjadi penting dan apa yang tidak penting; algoritma penguraian string yang sangat cepat mungkin tidak membantu jika program Anda terus-menerus menunggu di I / O, misalnya.

4. Dalam aplikasi web khususnya, Anda dapat fokus tidak hanya pada kinerja tetapi pada skala. Jika aplikasi dapat ditingkatkan, kinerja hampir tidak masalah, karena Anda dapat terus menambahkan node ke peternakan hingga cukup cepat.

5. Perhatian khusus diberikan pada basis data. Karena kendala integritas transaksional, database cenderung menjadi hambatan yang mendominasi setiap bagian dari sistem. Jika Anda memerlukan sistem berkinerja tinggi, pastikan Anda memiliki orang-orang berbakat yang bekerja di sisi basis data, meninjau rencana kueri, dan mengembangkan struktur tabel dan indeks yang akan membuat operasi umum seefisien mungkin.

Sebagian besar kegiatan ini bukan untuk awal atau akhir proyek tetapi harus dihadiri untuk terus menerus .

Saya seorang pengembang perangkat lunak junior dan saya bertanya-tanya kapan akan menjadi waktu terbaik untuk mengoptimalkan perangkat lunak untuk kinerja (kecepatan) yang lebih baik.

Pahami bahwa ada 2 ekstrem yang sangat berbeda.

Ekstrem pertama adalah hal-hal yang mempengaruhi sebagian besar desain, seperti bagaimana membagi pekerjaan menjadi berapa banyak proses dan / atau benang dan bagaimana bagian berkomunikasi (soket TCP / IP? Panggilan fungsi langsung?), Apakah akan menerapkan JIT tingkat lanjut atau juru bahasa "satu opcode pada satu waktu", atau apakah merencanakan struktur data agar dapat menerima SIMD, atau ... Hal-hal ini cenderung memiliki pengaruh yang kuat pada implementasi dan menjadi sangat sulit / mahal untuk disesuaikan setelahnya.

Ekstrem lainnya adalah mikro-optimisasi - tweak kecil di semua tempat. Hal-hal ini cenderung hampir tidak memiliki pengaruh pada implementasi (dan seringkali paling baik dilakukan oleh kompiler), dan itu sepele untuk membuat optimasi ini kapan pun Anda mau.

Di antara ekstrem ini adalah area abu-abu besar.

Apa yang sebenarnya terjadi adalah tebakan pengalaman / pendidikan yang digunakan untuk menjawab pertanyaan "apakah manfaatnya membenarkan biaya". Untuk optimisasi di / dekat satu ekstrim jika Anda salah menebak sering itu berarti membuang semua pekerjaan Anda dan memulai kembali dari awal atau kegagalan proyek (terlalu banyak waktu yang dihabiskan untuk desain yang terlalu rumit tidak perlu). Di / dekat ekstrim lainnya, jauh lebih masuk akal untuk membiarkannya sampai Anda dapat membuktikannya penting dengan menggunakan pengukuran (misalnya profiling).

Sayangnya kita hidup di dunia di mana terlalu banyak orang berpikir optimasi hanya mencakup hal-hal (kebanyakan tidak relevan) pada ekstrem "sepele".

Sangat mudah untuk menulis kode yang tidak porformant atau dipelihara. Lebih sulit untuk menulis kode porformant. Lebih sulit untuk menulis kode yang bisa dipelihara. Dan ini adalah yang paling sulit untuk menulis kode yang dapat dipelihara dan performan.

Tetapi, lebih mudah untuk membuat kode yang dapat dipelihara menjadi performant, daripada membuat kode yang dapat dipelihara dapat dipertahankan.

Sekarang, jelas, itu tergantung pada jenis sistem yang Anda buat, beberapa sistem akan sangat kritis terhadap kinerja dan kebutuhan yang direncanakan sejak awal. Bagi orang-orang yang sangat berbakat seperti Eric Lippert, yang menjawab di atas, sistem ini mungkin umum; tetapi bagi kebanyakan dari kita, mereka adalah minoritas dari sistem yang kita bangun.

Namun, mengingat keadaan perangkat keras modern, di sebagian besar sistem, tidak perlu memberikan perhatian khusus pada pengoptimalan sejak awal, melainkan menghindari penghancuran kinerja biasanya cukup. Yang saya maksud dengan ini adalah, hindari melakukan hal yang jelas-jelas bodoh seperti mengembalikan semua catatan tabel untuk mendapatkan hitungan alih-alih hanya menanyakan select count(*) from table. Hanya menghindari membuat kesalahan dan berusaha memahami alat yang Anda gunakan.

Selanjutnya, fokus pertama pada membuat kode Anda dapat dipertahankan. Dengan ini maksud saya adalah:

1. Pisahkan masalah seketat mungkin (misalnya, jangan gabungkan akses data dengan logika bisnis)
2. Referensi jenis abstrak daripada jenis beton jika memungkinkan
3. Jadikan kode Anda dapat diuji

Kode yang dapat dipertahankan jauh lebih mudah untuk dioptimalkan ketika statistik menunjukkan itu diperlukan.

Selanjutnya, pastikan kode Anda memiliki BANYAK tes otomatis, ini memiliki beberapa manfaat. Lebih sedikit bug berarti lebih banyak waktu untuk dioptimalkan, bila diperlukan . Juga, ketika Anda mengoptimalkan, Anda dapat beralih dan menemukan solusi terbaik lebih cepat karena Anda menemukan bug dalam implementasi Anda jauh lebih cepat.

Skrip penerapan otomatis dan infrastruktur skrip juga sangat berguna untuk penyesuaian kinerja, karena lagi-lagi, memungkinkan Anda untuk beralih lebih cepat; belum lagi manfaat lainnya.

Jadi, seperti biasa, ada pengecualian (yang Anda perlu pengalaman untuk mengidentifikasi dengan lebih baik), tetapi, secara umum, saran saya adalah: Pertama, pelajari alat Anda, dan hindari pengkodean hambatan kinerja. Kedua, pastikan kode Anda dapat dipertahankan. Ketiga, tes otomatis. Keempat, penyebaran yang sepenuhnya otomatis. Hanya setelah hal-hal ini selesai, Anda harus khawatir tentang pengoptimalan.

Saya mungkin bias bekerja di daerah yang sangat kritis terhadap kinerja seperti pemrosesan gambar dan raytracing, tapi saya masih mengatakan untuk mengoptimalkan "selambat mungkin" . Tidak peduli seberapa kritikal kinerja persyaratan Anda, selalu ada jauh lebih banyak informasi dan kejelasan di belakang, setelah Anda mengukur, daripada di muka, yang berarti bahkan optimasi paling efektif biasanya diterapkan kemudian setelah mendapatkan pengetahuan tersebut.

Kasus Aneh

Tetapi kadang-kadang "selambat mungkin" masih sangat awal dalam beberapa kasus aneh. Jika kita berbicara penyaji offline, misalnya, struktur data dan teknik yang Anda gunakan untuk mencapai kinerja benar-benar meresap ke dalam desain pengguna akhir. Ini mungkin terdengar menjijikkan tetapi bidangnya sangat canggih dan sangat kritis terhadap kinerja sehingga pengguna menerima kontrol akhir pengguna yang spesifik untuk teknik pengoptimalan yang berlaku untuk raytracer tertentu (mis: caching irradiance atau pemetaan foton), karena beberapa di antaranya digunakan untuk menunggu berjam-jam untuk membuat gambar, dan yang lain digunakan untuk mengeluarkan sejumlah besar uang untuk menyewa atau memiliki pertanian render dengan mesin yang didedikasikan untuk rendering. Ada pengurangan besar dalam waktu dan uang bagi para pengguna jika penyaji offline yang kompetitif dapat menawarkan pengurangan waktu yang dihabiskan untuk rendering yang tidak sepele. Ini adalah semacam area di mana pengurangan 5% dalam waktu sebenarnya menggairahkan pengguna.

Dalam kasus khusus seperti itu, Anda tidak bisa hanya memilih satu teknik rendering mau tak mau dan berharap untuk mengoptimalkannya nanti, karena seluruh desain, termasuk desain pengguna-akhir, berputar di sekitar struktur data dan algoritma yang Anda gunakan. Anda tidak dapat selalu hanya pergi dengan apa yang bekerja dengan baik untuk orang lain karena di sini, Anda, sebagai individu, dan kekuatan dan kelemahan khusus Anda, menjadi faktor penting dalam memberikan solusi kompetitif. Pola pikir dan kepekaan pengembang utama di belakang Arnold berbeda dari mereka yang bekerja pada VRay yang menggunakan pendekatan yang sangat berbeda; mereka tidak dapat selalu bertukar tempat / teknik dan melakukan pekerjaan terbaik (meskipun mereka berdua pemimpin industri). Anda harus melakukan eksperimen, prototipe, dan tolok ukur dan menemukan apa yang Anda inginkan. sangat baik dalam melakukan mengingat berbagai teknik canggih di luar sana jika Anda berharap untuk mengirimkan sesuatu yang kompetitif yang benar-benar akan dijual. Jadi dalam kasus khusus ini, masalah kinerja bergerak maju ke depan sebagai mungkin masalah yang paling penting sebelum memulai pengembangan.

Namun itu belum tentu merupakan pelanggaran untuk mengoptimalkan "selambat mungkin" , itu hanya "selambat mungkin" agak awal dalam kasus-kasus ekstrim dan aneh ini. Mencari tahu kapan dan juga apa yang tidak membutuhkan masalah kinerja awal, jika pernah sama sekali, mungkin merupakan tantangan utama bagi pengembang. Apa yang tidak dioptimalkan mungkin menjadi salah satu hal paling berharga untuk dipelajari dan terus dipelajari dalam karier seorang pengembang, karena Anda tidak dapat menemukan kekurangan pengembang naif yang ingin mengoptimalkan semuanya (dan sayangnya bahkan beberapa veteran yang entah bagaimana berhasil mempertahankan pekerjaan mereka di terlepas dari kontra-produktivitas mereka).

Selambat Mungkin

Mungkin bagian yang paling sulit adalah mencoba memahami artinya. Saya masih belajar dan saya sudah pemrograman selama hampir tiga dekade. Tetapi terutama sekarang dalam dekade ketiga saya, saya mulai menyadari bahwa itu tidak sulit. Ini bukan ilmu roket, jika Anda lebih fokus pada desain daripada implementasi. Semakin banyak desain Anda meninggalkan ruang bernafas untuk optimasi yang tepat nanti tanpa perubahan pada desain, semakin Anda dapat mengoptimalkan. Dan semakin banyak produktivitas yang saya peroleh dengan mencari desain seperti itu yang memberi saya ruang bernapas.

Desain Yang Menawarkan Ruang Pernapasan untuk Dioptimalkan Nanti

Jenis desain ini sebenarnya tidak terlalu sulit untuk dicapai dalam banyak kasus jika kita dapat menerapkan "akal sehat". Sebagai kisah pribadi saya menjadi seni visual sebagai hobi (saya merasa agak membantu memprogram perangkat lunak bagi para seniman untuk memahami kebutuhan mereka dan berbicara dalam bahasa mereka), dan saya menghabiskan beberapa waktu di awal tahun 2000 menggunakan applet Oekaki online sebagai cara cepat untuk mencorat-coret dan berbagi karya saya dan terhubung dengan artis lain.

Khususnya situs dan applet favorit saya di sana penuh dengan cacat kinerja (ukuran kuas non-sepele akan lambat merangkak), tetapi memiliki komunitas yang sangat bagus. Untuk mengatasi masalah kinerja saya menggunakan sikat kecil 1 atau 2-pixel kecil dan hanya menulis pekerjaan saya seperti:

Sementara itu saya terus memberi penulis saran perangkat lunak untuk meningkatkan kinerja, dan dia memperhatikan saran saya yang bersifat teknis berbicara tentang optimasi memori dan algoritma dan sebagainya. Jadi dia benar-benar bertanya apakah saya seorang programmer dan saya menjawab ya dan dia mengundang saya untuk bekerja pada kode sumber.

Jadi saya melihat kode sumber, menjalankannya, memprofilkannya, dan yang mengejutkan saya ia telah merancang perangkat lunak di sekitar konsep "antarmuka pixel abstrak", seperti IPixel, yang akhirnya menjadi akar penyebab di balik hotspot teratas untuk semuanya dengan dinamis alokasi dan pengiriman untuk setiap piksel tunggal dari setiap gambar tunggal. Namun tidak ada cara praktis untuk mengoptimalkan itu tanpa mempertimbangkan kembali seluruh desain perangkat lunak karena desain telah menjebaknya ke sudut di mana tidak ada banyak di luar yang paling sepele dari optimasi mikro ketika abstraksi kami bekerja pada tingkat granular dari satu piksel abstrak tunggal dan semuanya tergantung pada pixel abstrak ini.

Saya pikir itu pelanggaran "akal sehat" tapi jelas itu bukan akal sehat pengembang. Tapi itu seperti tidak melakukan hal-hal abstrak pada tingkat granular di mana bahkan kasus penggunaan paling dasar akan menjadi instantiating oleh jutaan, seperti dengan piksel, atau partikel, atau unit kecil dalam simulasi pasukan ginormous. Mendukung IImage(Anda dapat menangani semua format gambar / piksel yang Anda butuhkan pada tingkat agregat yang lebih besar) atau IParticleSystemke IPixelatau IParticle, dan kemudian Anda dapat memasukkan implementasi yang paling dasar dan cepat untuk menulis dan mudah dipahami di balik antarmuka dan memiliki semua ruang bernafas yang Anda perlukan untuk mengoptimalkan nanti tanpa mempertimbangkan kembali seluruh desain perangkat lunak.

Dan itulah tujuannya seperti yang saya lihat hari ini. Tidak termasuk kasus aneh seperti penyaji offline di atas, desain dengan ruang bernapas yang cukup untuk mengoptimalkan selambat mungkin, dengan informasi belakang sebanyak mungkin (termasuk pengukuran), dan menerapkan optimasi yang diperlukan selambat mungkin.

Tentu saja saya tidak menyarankan untuk memulai menggunakan algoritma kompleksitas kuadrat pada input yang dengan mudah mencapai ukuran non-sepele dalam kasus umum pengguna akhir. Lagi pula siapa yang melakukan itu? Tapi saya bahkan tidak berpikir itu masalah besar jika implementasinya mudah untuk ditukar nanti. Itu masih bukan kesalahan besar jika Anda tidak harus mempertimbangkan kembali desain apa pun.

Itu tergantung pada apa arti kinerja itu bagi aplikasi Anda. Dan apakah mungkin untuk mengoptimalkan kinerja sebelum aplikasi Anda secara fungsional selesai.

Paling sering Anda tidak perlu khawatir tentang hal itu sampai Anda tidak memiliki sesuatu yang lebih baik untuk dilakukan, tetapi bisa jadi tingkat kinerja tertentu sangat penting untuk keberhasilan aplikasi Anda. Jika itu yang terjadi dan Anda curiga itu tidak mudah, Anda harus mulai melihat kinerja demi "gagal cepat".

Prinsip penting untuk setiap proyek adalah fokus pada bagian-bagian yang sulit terlebih dahulu. Dengan begitu, jika ternyata Anda tidak bisa melakukannya, Anda akan tahu lebih awal dan akan ada waktu untuk mencoba sesuatu yang sama sekali berbeda atau proyek mungkin dibatalkan sebelum terlalu banyak dihabiskan untuk itu.

Saya akan menyarankan kinerja lebih dari kecepatan. Ini termasuk skala (ratusan hingga ribuan pengguna bersamaan). Yang pasti Anda tidak ingin aplikasi untuk tangki ketika mendapat beban produksi. Kinerja mencakup berapa banyak sumber daya (misalnya memori) yang dikonsumsi aplikasi.

Performanya juga mudah digunakan. Beberapa pengguna lebih suka 1 keystroke melakukan tugas dalam 10 detik daripada 2 stroke kunci melakukan tugas dalam 1 detik. Untuk hal-hal seperti itu tanyakan desain Anda. Saya tidak suka membawa barang-barang seperti ini kepada pengguna lebih awal. Dalam ruang hampa mereka dapat mengatakan X tetapi begitu mereka bekerja dengan fungsional pra-rilis mereka mungkin mengatakan Y.

Kecepatan individu terbaik adalah memegang sumber daya seperti koneksi basis data. Tetapi untuk skala Anda harus mendapatkan koneksi selambat mungkin dan melepaskannya sesegera mungkin. Satu perjalanan ke database untuk mendapatkan 3 hal lebih cepat dari 3 perjalanan terpisah ke database.

Apakah Anda melakukan perjalanan untuk informasi yang tidak berubah selama sesi. Jika demikian, dapatkan di sesi mulai dan tahan itu adalah memori.

Saat memilih jenis koleksi pertimbangkan fungsional, kecepatan, dan ukuran.

Apakah Anda yakin perlu menyimpan item dalam koleksi? Masalah umum di sana adalah membaca semua baris dari file ke dalam daftar dan kemudian memproses daftar satu baris sekaligus. Jauh lebih efisien untuk membaca file satu per satu dan melewatkan daftarnya.

Apakah Anda mengulang tiga kali ketika Anda bisa mengulang sekali dan melakukan tiga hal.

Apakah ada tempat di mana Anda mungkin perlu memproses utas lainnya dengan menelepon kembali. Jika demikian kemas kode dengan kebutuhan yang mungkin ada dalam pikiran jika tidak mengganggu kebutuhan desain langsung.

Banyak kinerja juga kode bersih.

Ada optimasi prematur dan hanya melakukan hal-hal yang masuk akal di depan yang tidak benar-benar memakan waktu lebih lama.

Dalam database adalah tempat saya melihat optimasi prematur. Akan dinormalisasi untuk kecepatan sebelum ada masalah kecepatan. Argumen yang saya dapatkan adalah jika kita mengubah tabel nanti maka kita harus mengubah segalanya. Seringkali Anda dapat membuat tampilan menyajikan data seperti itu dan mungkin perlu ditukar untuk tabel yang dinormalisasi nanti.