Pada zaman komputasi modern, dalam 'aplikasi bisnis biasa' - mengapa kinerja penting? [Tutup]

Ini mungkin tampak seperti pertanyaan aneh bagi sebagian dari Anda.

Saya seorang programmer Java hobbyist. Saya telah mengembangkan beberapa permainan, program AI yang menciptakan musik, program lain untuk melukis, dan hal-hal serupa. Ini untuk memberi tahu Anda bahwa saya memiliki pengalaman dalam pemrograman, tetapi tidak dalam pengembangan profesional aplikasi bisnis.

Saya melihat banyak pembicaraan di situs ini tentang kinerja. Orang-orang sering memperdebatkan apa yang akan menjadi algoritma paling efisien dalam C # untuk melakukan tugas, atau mengapa Python lambat dan Java lebih cepat, dll.

Apa yang saya coba pahami adalah: mengapa ini penting?

Ada area spesifik komputasi di mana saya melihat mengapa kinerja penting: permainan, di mana puluhan ribu komputasi terjadi setiap detik dalam loop pembaruan konstan, atau sistem tingkat rendah yang diandalkan oleh program lain, seperti OS dan VM, dll.

Tetapi untuk aplikasi bisnis tingkat tinggi yang normal dan khas, mengapa kinerja penting?

Saya bisa mengerti mengapa itu penting, beberapa dekade yang lalu. Komputer jauh lebih lambat dan memiliki memori jauh lebih sedikit, jadi Anda harus berpikir dengan hati-hati tentang hal-hal ini.

Tetapi hari ini, kami memiliki begitu banyak memori untuk cadangan dan komputer sangat cepat: apakah benar - benar penting jika algoritma Java tertentu adalah O (n ^ 2)? Apakah ini akan benar-benar membuat perbedaan bagi pengguna akhir dari aplikasi bisnis khas ini?

Ketika Anda menekan tombol GUI di aplikasi bisnis biasa, dan di balik layar itu menggunakan algoritma O (n ^ 2), di zaman komputasi modern - apakah Anda benar-benar merasakan inefisiensi?

Pertanyaan saya terbagi dua:

1. Dalam praktiknya, hari ini apakah kinerja penting dalam program bisnis normal?
2. Jika ya, tolong beri saya contoh tempat di dunia nyata dalam aplikasi semacam itu, di mana kinerja dan optimalisasi sangat penting.

Anda benar, kinerja dalam aplikasi bisnis sebenarnya bukan subjek yang penting seperti yang dibahas oleh sebagian besar programmer . Biasanya, diskusi terkait kinerja yang saya dengar dari programmer memiliki beberapa masalah:

• Mereka sebagian besar optimasi prematur . Biasanya, seseorang menginginkan "cara tercepat" untuk melakukan operasi tanpa alasan yang jelas, dan akhirnya membuat perubahan kode yang dibuat oleh sebagian besar penyusun (seperti mengganti pembagian dengan penggandaan atau inlining suatu metode), atau menghabiskan waktu berhari-hari untuk membuat perubahan yang akan membantu mendapatkan beberapa mikrodetik saat runtime.

• Mereka sering bersifat spekulatif . Saya senang melihat bahwa pada Stack Overflow dan Programmer.SE, pembuatan profil sering disebutkan ketika pertanyaan terkait dengan kinerja, tapi saya juga kecewa ketika saya melihat dua programmer yang tidak tahu profil apa yang membahas tentang kinerja- perubahan terkait yang harus mereka lakukan dalam kode mereka. Mereka percaya perubahan akan membuat segalanya lebih cepat, tetapi secara praktis setiap waktu, itu tidak akan memiliki efek yang terlihat atau memperlambat segalanya, sementara seorang profiler akan mengarahkan mereka ke bagian lain dari kode yang dapat dengan mudah dioptimalkan dan yang membuang 80% waktu.

• Mereka fokus pada aspek teknis saja. Kinerja aplikasi yang berorientasi pada pengguna adalah tentang perasaan: apakah terasa cepat dan responsif, atau apakah terasa lambat dan kikuk? Dalam konteks ini, masalah kinerja biasanya diselesaikan jauh lebih baik oleh desainer pengalaman pengguna: transisi animasi sederhana sering kali merupakan perbedaan antara aplikasi yang terasa sangat lambat dan aplikasi yang terasa responsif, sementara keduanya menghabiskan 600 ms. melakukan operasi.

• Mereka didasarkan pada elemen subjektif bahkan ketika mereka terkait dengan kendala teknis. Jika ini bukan masalah perasaan cepat dan responsif, harus ada persyaratan non-fungsional yang menentukan seberapa cepat operasi harus dilakukan pada data tertentu, berjalan pada sistem tertentu . Pada kenyataannya, itu terjadi lebih seperti itu: manajer mengatakan bahwa ia menemukan sesuatu yang lambat, dan kemudian, pengembang perlu mencari tahu apa artinya itu. Apakah lambat seperti di "seharusnya di bawah 30 ms. Sedangkan saat ini, itu buang sepuluh detik", atau lambat seperti "kita mungkin bisa menurunkan durasinya dari sepuluh menjadi sembilan detik"?

Di awal karier saya sebagai seorang programmer, saya mengerjakan perangkat lunak untuk sekelompok pelanggan saya. Saya yakin perangkat lunak ini adalah hal besar berikutnya yang akan membawa kebahagiaan bagi dunia, jadi saya jelas peduli dengan kinerja.

Saya pernah mendengar istilah seperti "profiling" atau "tolok ukur", tetapi saya tidak tahu apa artinya dan tidak peduli. Selain itu, saya terlalu fokus membaca buku tentang C, dan terutama bab di mana teknik optimasi dibahas. Ketika saya menemukan bahwa komputer melakukan perkalian lebih cepat daripada pembagian, saya mengganti pembagian dengan perkalian di mana pun saya bisa. Ketika saya menemukan bahwa memanggil metode bisa lambat, saya menggabungkan metode sebanyak yang saya bisa, seolah-olah 100 metode LOC sebelumnya belum menjadi masalah.

Kadang-kadang, saya menghabiskan malam melakukan perubahan yang, saya yakin, membuat perbedaan antara aplikasi lambat yang tidak diinginkan, dan yang cepat yang ingin diunduh dan digunakan semua orang. Fakta bahwa dua pelanggan sebenarnya yang tertarik dengan aplikasi ini meminta fitur-fitur aktual tidak mengganggu saya: "Siapa yang mau fitur, jika aplikasi lambat?" - Saya pikir.

Akhirnya, hanya dua pelanggan yang berhenti menggunakan aplikasi. Itu tidak luar biasa cepat terlepas dari semua usaha saya, terutama karena ketika Anda tidak tahu apa itu indeks dan aplikasi Anda intensif basis data, ada sesuatu yang salah. Lagi pula, ketika saya melakukan perubahan lain yang terkait dengan kinerja, yang ditingkatkan dengan beberapa mikrodetik pelaksanaan kode yang digunakan sebulan sekali, pelanggan tidak melihat perubahan. Apa yang mereka lihat adalah bahwa pengalaman pengguna mengerikan, dokumentasi hilang, fitur penting yang mereka minta selama berbulan-bulan tidak ada di sini dan jumlah bug untuk dipecahkan terus meningkat.

Hasil: Saya berharap aplikasi ini akan digunakan oleh ribuan perusahaan di seluruh dunia, tetapi hari ini, Anda tidak akan menemukan informasi tentang aplikasi ini di internet. Hanya dua pelanggan yang meninggalkannya, dan proyek itu juga ditinggalkan. Itu tidak pernah dipasarkan, tidak pernah diiklankan secara publik, dan hari ini, saya bahkan tidak yakin saya dapat mengkompilasinya di PC saya (atau menemukan sumber aslinya). Ini tidak akan terjadi jika saya lebih fokus pada hal-hal yang sebenarnya penting.

Karena itu, kinerja secara umum adalah penting :

• Dalam aplikasi non-bisnis, ini bisa menjadi sangat penting. Ada perangkat lunak tertanam , perangkat lunak dijalankan pada server (ketika Anda memiliki beberapa ribu permintaan per detik, yang tidak sebesar itu, kinerja mulai menjadi perhatian), perangkat lunak dijalankan pada telepon pintar , video game , perangkat lunak untuk profesional (cobalah untuk menangani file 50 GB di Photoshop pada mesin yang tidak terlalu cepat untuk diyakinkan) dan bahkan produk perangkat lunak biasa yang dijual kepada banyak orang (jika Microsoft Word menghabiskan dua kali waktu untuk melakukan setiap operasi yang dilakukannya, waktu yang hilang dikalikan dengan angka pengguna akan menjadi masalah).

• Dalam aplikasi bisnis, ada banyak kasus di mana sebuah aplikasi yang terasa dan merupakan lambat akan dibenci oleh pengguna. Anda tidak menginginkan hal itu, membuat kinerja menjadi perhatian Anda.

Iya nih. Ya, benar. Kecepatan run-time bukan satu-satunya masalah yang harus Anda hadapi, dan itu tidak sepesat seperti pada tahun 1982, atau karena masih ada pada sistem tertanam bertenaga rendah, tetapi selalu menjadi perhatian, dan penting bagi Anda untuk memahami mengapa demikian?

Pertama, kompleksitas asimptotik yang Anda sebutkan menggambarkan perilaku program saat ukuran inputnya bertambah . Program non-linier yang menangani 10 item bisa lolos dari melakukan pekerjaan yang berlebihan, tetapi itu akan menggigit Anda ketika suatu hari Anda harus berurusan dengan 1000, karena itu tidak hanya akan terlihat lebih lambat, tetapi jauh, jauh lebih lambat. Dan Anda tidak tahu (tanpa analisis dan tolok ukur yang luas) apakah poin itu akan mencapai 100 item, 1000 item, atau tidak hingga Anda mencapai 100.000 item. Mungkin sulit dipercaya, tetapi memilih algoritme terbaik sebagai hal yang biasa sebenarnya jauh lebih mudah daripada memperkirakan titik ini untuk setiap rutin dan memilih implementasi Anda tergantung pada perkiraan ini.

Baca juga tentang dasar-dasar pengalaman pengguna. Ada ambang yang diteliti dengan baik yang menentukan bagaimana interaksi dengan suatu program dirasakan tergantung pada waktu responsnya (10 ms, 100 ms, beberapa detik, dll.). Melewati salah satu ambang batas ini akan menyebabkan pengguna melepaskan diri dari aplikasi Anda, dan kecuali Anda berada dalam posisi senang menulis perangkat lunak monopoli yang harus digunakan orang, pengguna yang terlepas menerjemahkan langsung ke nilai bisnis negatif karena hal itu menyebabkan hilangnya pelanggan.

Ini hanya beberapa alasan mengapa seorang programmer profesional harus tahu tentang kompleksitas algoritmik dan menanganinya secara bertanggung jawab. Hari-hari ini biasanya tidak perlu keluar dari jalan dan program Anda terutama dioptimalkan, kode yang dapat dibaca buruk untuk apa pun kecuali ternyata itu adalah loop dalam waktu-kritis, tetapi Anda tidak boleh, pernah meminta kelas kompleksitas lebih tinggi daripada yang jelas diperlukan untuk melakukan pekerjaan itu.

Ya itu!

Karena Anda meminta contoh, beberapa situasi setiap hari muncul di benak Anda:

1. Menangani big-data : Banyak aplikasi bisnis didukung oleh basis data dan dalam banyak kasus basis data ini dipenuhi dengan data. Dan karena ruang drive murah, jumlah data yang direkam dan disimpan gila. Baru minggu lalu seorang pelanggan mengeluh, bahwa aplikasinya sangat lambat, ketika hanya menampilkan beberapa angka rata-rata (permintaan lebih dari beberapa juta baris ...) - Juga dalam penggunaan sehari-hari kami memiliki konversi dan kalkulasi data-batch dengan runtime di liga beberapa jam. Tahun lalu optimasi algoritmik membawa waktu proses satu batch berjalan dari 8 menjadi 4 jam, sekarang tidak bertabrakan dengan shift hari lagi!

2. Responsif : Ada studi kegunaan (jika saya punya waktu saya akan menambahkan tautan ke pertanyaan yang relevan di ux.se ...) bahwa kepuasan pengguna sangat terkait dengan responsif. Perbedaan dalam waktu respons 200ms vs 400ms dapat dengan mudah membebani Anda dengan persentase besar pelanggan yang meninggalkan Anda untuk pesaing Anda.

3. Sistem Tertanam : Komputer tidak semakin cepat, semakin lambat dan semakin kecil ^ _ ^ Pengembangan seluler memiliki dampak besar pada pengembangan aplikasi. Tentu kita dapat membuang siklus memori dan CPU seperti Jelly Beans di komputer Desktop modern, tetapi sekarang bos Anda meminta Anda untuk menerapkan algoritma penganalisa tidur pada jam tangan freakin atau pada SIM-Card ...

Dalam praktiknya, hari ini apakah kinerja penting dalam program bisnis normal?

Saya tidak tahu apa itu program bisnis normal. Yang saya tahu, adalah bahwa pengguna selalu berakhir dengan memberi makan program kami dengan lebih banyak data dari yang kami rencanakan (sering setelah memberi tahu mereka seberapa besar itu dan menambahkan margin keamanan) dan bahwa dalam kasus itu, mereka mengharapkan peningkatan linear dari run-time, terima perilaku log dan mengeluh bahwa aplikasi membeku ketika hal lain terjadi. Dan mereka cenderung mempertimbangkan ukuran hasil lebih dari ukuran input kecuali dalam kasus di mana jelas dari POV mereka bahwa semua data input harus diproses.

Jadi ya, kinerja, setidaknya pada tingkat kompleksitas, penting. Optimalisasi mikro di dalam kelas kompleksitas tidak terlalu penting, kecuali jika Anda terlihat lebih buruk daripada pesaing (baik dalam tolok ukur di beberapa pasar atau dengan persepsi mentah - mengubah kelas dalam progres "instan", "tidak instan tetapi pengguna tidak dapat beralih ke sesuatu yang lain "," cukup lambat sehingga pengguna beralih ke sesuatu yang lain dengan risiko mengganggu aliran tindakan "," cukup lambat sehingga pengguna meluncurkan tugas dan kemudian memeriksa dari waktu ke waktu "," cukup lambat bahwa pengguna berencana untuk meluncurkan tugas saat makan siang, malam, selama akhir minggu ").

Dalam aplikasi bisnis modern, masalah kinerja bukan dalam bentuk kekurangan CPU atau memori. Tetapi mereka dalam bentuk latensi jaringan, kinerja I / O dan abstraksi menyembunyikan semua itu. Itu semua tergantung pada seberapa baik desain dan seberapa berpengalaman pengembangnya. Bahkan aplikasi CRUD sederhana dapat merangkak berhenti jika menarik dari DB satu baris pada satu waktu alih-alih menjalankan kueri (juga dikenal sebagai masalah N +1).

Masalahnya adalah memiliki desain yang bagus dan pengembang yang berpengalaman itu mahal. Dan biasanya jauh lebih murah untuk membuat pengguna jengkel daripada berinvestasi ke dalam optimasi kinerja aktual. Ada beberapa kasus, di mana pelanggan akan membutuhkan kinerja tinggi (mis. Browser web), tetapi hal itu jarang berlaku untuk aplikasi bisnis umum.

Ingatlah bahwa untuk aplikasi berbasis server, Anda mungkin memiliki ratusan, ribuan atau bahkan jutaan pengguna yang mencoba melakukan sesuatu pada saat yang bersamaan. Penghematan kecil dalam efisiensi dalam situasi seperti itu dapat berdampak besar pada jumlah perangkat keras yang diperlukan untuk permintaan layanan.

Ini tentu sangat penting.

Masalah utama adalah tidak bahkan tentang menjadi menjengkelkan bagi pengguna, seperti mengalami penundaan perlu ketika elemen GUI yang tekor dua atau tiga kali (yang tidak peduli pada grafis terintegrasi!) Atau hanya karena program mengambil begitu lama untuk melakukan ... apa pun tidak (kebanyakan hal tidak menarik). Meskipun tentu saja, itu juga merupakan masalah.

Ada tiga kesalahpahaman penting:

1. Kebanyakan komputer bisnis biasa tidak "jauh lebih kuat" . Komputer bisnis biasa bukan i7 8-core dengan kartu grafis kick-ass dan 16GB RAM. Ini adalah notebook dengan prosesor ponsel kelas menengah, grafik terintegrasi, 2GB memori utama (4GB jika Anda beruntung), disk 5400RPM, dan versi Windows untuk perusahaan dengan berbagai antivirus realtime dan perangkat lunak penegakan kebijakan yang berjalan di Latar Belakang. Atau, bagi sebagian besar konsultan, "komputer" hanyalah iPhone ...
2. Sebagian besar "pengguna bisnis biasa" bukan teknisi, mereka tidak memahami implikasi membuat spreadsheet dengan 10-12 tab referensi silang, 150 kolom, dan 30.000 baris (angka-angka ini tidak realistis seperti yang Anda kira!) Dan mereka juga tidak ingin tahu. Mereka hanya akan melakukannya.
3. Kehilangan kedua bukan biaya adalah asumsi yang salah.

Istri saya bekerja di ujung atas "lingkungan bisnis yang khas". Komputer yang ia gunakan harganya sekitar 3,5 jam dari waktu kerjanya layak. Memulai Microsoft Outlook membutuhkan - pada hari yang baik - sekitar 3 menit hingga siap (6-8 menit pada akhir kuartal ketika server berada di bawah beban berat). Beberapa spreadsheet 30k-baris yang disebutkan membutuhkan waktu 2-3 detik untuk memperbarui nilai di mana komputer "dibekukan" (belum lagi berapa lama waktu yang diperlukan Excel untuk memulai dan membukanya di tempat pertama!). Lebih buruk lagi ketika berbagi desktop. Bahkan jangan biarkan saya menggunakan SAP.
Tentu penting apakah seratus ribu orang masing-masing kehilangan 20-25 menit per hari kerja tanpa menunggu apa pun. Itu jutaan yang hilangyang Anda bisa, bukannya kehilangan mereka, membayar sebagai dividen (atau membayar upah lebih tinggi).
Tentu, sebagian besar karyawan berada di ujung bawah bayaran, tetapi bahkan pada ujung bawah adalah uang .

Saya bisa mengerti mengapa itu penting, beberapa dekade yang lalu. Komputer jauh lebih lambat dan memiliki memori jauh lebih sedikit, jadi Anda harus berpikir dengan hati-hati tentang hal ini.

Anda tampaknya meremehkan seberapa cepat N ^ 2 tumbuh. Katakanlah kita memiliki komputer dan algoritma N ^ 2 kita membutuhkan waktu 10 detik ketika N = 10. Waktu berlalu sekarang kita memiliki prosesor baru yang 6 kali lebih cepat dari yang asli sehingga perhitungan 10 detik kita sekarang kurang dari dua detik. Seberapa besar N dapat dan masih muat dalam waktu 10 detik aslinya? Kami sekarang dapat menangani 24 item, sedikit lebih dari dua kali lipat. Seberapa cepat sistem kita harus menangani barang 10 kali lebih banyak? Yah itu harus 100 kali lebih cepat. Data tumbuh cukup cepat dan lebih dari sekadar menghapus kemajuan perangkat keras komputer untuk algoritma N ^ 2.

Anda tidak akan percaya jumlah program bisnis pihak ke-3 yang kami gunakan di tempat kerja, dan banyak di antaranya sangat lambat digunakan dibandingkan dengan standar pribadi saya. Jika program itu adalah sesuatu yang saya gunakan di rumah, saya akan menggantinya dengan yang lama.

Dalam beberapa kasus, perbedaannya langsung ke biaya, karena beberapa program secara langsung mempengaruhi berapa banyak tugas yang dapat saya selesaikan dalam sehari, dan dengan demikian menurunkan produktivitas dan jumlah barang yang bisa ditagih. Jadi saya akan mengatakan itu cukup penting untuk program bisnis juga, untuk menjadi setidaknya berkinerja cukup untuk tidak menjadi item pembatas penghasilan.

Contohnya adalah manajemen insiden di mana pekerjaan diukur dalam interval 15 menit (meja layanan). Jika program ini cukup lambat untuk mendorong satu tiket untuk mengambil lebih dari 15 menit (termasuk pekerjaan yang sebenarnya), itu akan memperlambat prosesnya cukup banyak. Salah satu penyebabnya adalah akses database yang lambat yang hanya "menunggu sebentar" setiap kali pengguna melakukan tindakan (mengisi detail resolusi, memperbarui informasi pekerjaan, atau yang serupa). Saya bisa membayangkan ada kasus di mana program lambat bahkan dapat mempengaruhi hal-hal yang lebih kritis, seperti rincian pasien rumah sakit pada kasus keracunan yang mendesak - mungkin alergi obat atau semacamnya?

Banyak jawaban lain membahas topik itu dengan cukup teliti, jadi saya menundanya dengan alasan dan alasan. Sebaliknya, saya ingin memberikan contoh kehidupan nyata untuk menunjukkan bagaimana pilihan algoritmik dapat memiliki implikasi nyata.

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

Artikel yang ditautkan menjelaskan bug dalam algoritme untuk menghitung pembaruan Windows XP. Untuk sebagian besar kehidupan Windows XP, algoritma pembaruan bekerja dengan baik. Algoritma menghitung apakah suatu tambalan telah digantikan oleh tambalan yang lebih baru, dan dengan demikian tidak perlu diinstal. Namun, menjelang akhir, daftar pembaruan yang digantikan tumbuh sangat lama *.

Algoritma pembaruan bersifat eksponensial, di mana setiap pembaruan baru membutuhkan waktu dua kali lebih lama untuk menghitung seperti yang sebelumnya ( ). Ketika daftar naik ke kisaran pembaruan 40 (* panjang ), butuh hingga 15 menit, berjalan pada kapasitas penuh, untuk memeriksa pembaruan. Ini secara efektif mengunci banyak mesin XP selama pembaruan. Lebih buruk lagi, ketika seseorang akan menginstal pembaruan, algoritma akan berjalan lagiO(n) = 2n , membutuhkan waktu 15 menit. Karena banyak mesin memiliki Pembaruan Otomatis, ini dapat mengunci mesin selama 15 menit pada setiap boot, dan berpotensi lagi pada periode tertentu.

Microsoft menggunakan kedua peretasan jangka pendek (menghapus item dari daftar pembaruan) dan perbaikan jangka panjang untuk mengatasi masalah ini. Ini penting karena versi terbaru Windows juga menggunakan algoritma yang sama, dan mungkin suatu hari menghadapi masalah yang sama.

Di sini kita dapat melihat bahwa pilihan suatu algoritma memiliki implikasi nyata. Algoritme yang salah, meskipun baik untuk sebagian besar umur produk, masih dapat memiliki dampak negatif di jalan.

Saya pikir Anda menafsirkan jumlah pertanyaan yang diajukan tentang kinerja sebagai indikasi bahwa persyaratan kinerja untuk aplikasi bisnis adalah penting daripada mengakui bahwa meningkatkan kinerja sulit . Hanya membuatnya bekerja dapat dicapai dengan teknik brute-force, trial and error atau menyalin dan menempelkan kode contoh.

Siapa pun bisa beruntung dan terus membuat perubahan sampai sesuatu berjalan lebih cepat, tetapi itu jarang berhasil. Karena kurangnya pengalaman, pengembang akan melihat bantuan dari luar. Di beberapa lingkungan, peningkatan kinerja adalah masalah unik, jadi mengajukan pertanyaan spesifik di situs seperti StackOverflow mungkin satu-satunya pilihan. Selain itu, banyak konsultan menghasilkan uang dengan bisa turun tangan dan memperbaiki masalah-masalah semacam ini.

Itu sangat tergantung pada bagaimana Anda mendefinisikan "kinerja yang baik". Algoritme Anda harus selalu menggunakan kompleksitas sebaik mungkin. Abuse celah untuk mempercepat kandang rata-rata Anda. Buffer dan preload / precompile sedapat mungkin dalam program interaktif.

Ada definisi lain tentang "kinerja yang baik": Mengoptimalkan konstanta kelas kompleksitas Anda. Di sinilah C ++ mendapatkan gelarnya, di mana orang mulai memanggil Java lambat, di mana runtime 5% lebih sedikit tampaknya menjadi grail suci. Menggunakan definisi ini, Anda benar. Perangkat keras komputer menjadi semakin rumit dengan waktu, sementara kompiler menjadi lebih baik dan lebih baik. Pada titik tertentu Anda tidak dapat benar-benar mengoptimalkan kode low end lebih baik daripada kompiler - jadi biarkan saja dan berkonsentrasi pada algoritma Anda.

Pada saat itu menggunakan Java / Haskell / C ++ menjadi hanya keputusan desain. Pencacahan angka dapat dilakukan melalui OpenCL pada GPU Anda. User Interface membutuhkan algoritma waktu konstan dan mereka bagus. Output dan modularitas lebih penting daripada menyelaraskan kelas Anda untuk pemanfaatan cache 20% lebih baik. Multithreading menjadi penting, karena orang tidak menginginkan aplikasi yang cepat, mereka menginginkan yang responsif. Yang tidak penting adalah aplikasi Anda secara konstan lebih lambat 10% dari seharusnya. Bahkan 50% tidak masalah (tetapi orang-orang mulai bertanya kemudian). Berkonsentrasi pada kebenaran, daya tanggap dan modularitas.

Saya suka pemrograman di Haskell atau setidaknya dalam bentuk fungsional (bahkan di C ++). Mampu menulis tes dengan mudah untuk seluruh program Anda jauh lebih penting daripada menjadi sedikit lebih cepat dalam pekerjaan batch.

Cukup sederhana: biaya

Majikan saya sebelumnya memiliki sistem manajemen pembelajaran yang di-host di server fisik sebagai model SaaS. Tumpukan JVM dikonfigurasikan menjadi 2 GB untuk mesin yang lebih lama dan 3 GB untuk mesin yang lebih baru dan kami menjalankan beberapa instance per mesin. Anda akan berpikir itu sudah cukup.

Sebelum saya mulai, ada tim kinerja yang bertanggung jawab untuk membuat sistem responsif dan berskala. Mereka menemukan bahwa ada bagian-bagian tertentu dari data yang kami tanyakan dari basis data secara konstan. Ada satu tabel yang kami gabungkan ke sebagian besar kueri untuk mengambil satu kolom. Data itu jarang berubah.

Masalahnya adalah, kami memiliki 2 GB untuk bekerja. Jadi solusi yang jelas adalah mulai melakukan caching semua data yang sering dibaca. Lalu kami memiliki masalah memori, mulai tepat sebelum saya naik kapal.

Ada 2 aliran pemikiran tentang ini:

1. Memori dan perangkat keras pada umumnya murah saat ini. Beli saja lebih banyak RAM sehingga Anda dapat menyimpan lebih banyak.
2. Mengapa sistem manajemen pembelajaran membutuhkan 3+ GB RAM? Semua itu itu mengeluarkan pertanyaan SQL, mengirim arahan ulang untuk meluncurkan kursus, dan mengevaluasi kemajuan siswa melalui kursus.

Argumen kedua menang dan saya menghabiskan lebih dari setahun menyesuaikan penggunaan memori kita.

Majikan saya saat ini juga menyelenggarakan sistem pengelolaan pembelajaran, tetapi menyelenggarakannya sedikit berbeda. Skalabilitasnya sangat buruk sehingga instalasi tunggal (dibagi menjadi 4 server virtual seimbang) hanya dapat menangani 80 pelanggan. Beberapa pelanggan kami yang lebih besar bahkan mendapatkan server mereka sendiri. Sebagian besar masalah yang mengarah ke masalah ini adalah masalah kinerja, seperti kueri SQL yang menahan semua siklus CPU, kebocoran memori, kode berlebihan yang melakukan hal yang sama beberapa kali. Kami bahkan memiliki aplikasi internal yang dibangun yang tujuan utamanya adalah me-restart server ketika kinerjanya tidak buruk. Ada seorang karyawan yang memelihara alat itu (bersama dengan tanggung jawab lainnya).

Mereka berlangganan pemikiran pertama yang saya sebutkan di atas: melemparkan lebih banyak perangkat keras karena biaya perangkat keras lebih murah daripada gaji pengembang.

Ini tidak berhasil secara ekonomis seperti yang diharapkan. Antara perangkat keras, lisensi perangkat lunak, dan personel pendukung untuk menangani server, kami menghabiskan jutaan setiap tahun untuk menghindari pengembang menghabiskan waktu membuat kode profil.

Ketika saya bergabung, saya bertanggung jawab untuk memperbaiki masalah ketersediaan kami. Karena sebagian besar masalah ketersediaan kami disebabkan oleh kinerja yang buruk, saya telah melakukan penyetelan kinerja kode kami dan skalabilitasnya secara substansial ditingkatkan, dengan uptime yang jauh lebih baik. Kami siap untuk mulai meningkatkan kepadatan. Tak perlu dikatakan, gaji saya tidak mendekati satu juta (saya berharap!), Jadi menghabiskan uang untuk memiliki saya kinerja menyempurnakan kode akan berakhir menyelamatkan kita jutaan per tahun.

TL; DR

Jika Anda melakukan analisis biaya / manfaat secara menyeluruh, Anda akan melihat bahwa lebih murah untuk hanya memperbaiki kodenya. Masalah kinerja yang diketahui yang Anda abaikan berubah menjadi utang teknis .

Saya memahami pertanyaan Anda seperti ini: untuk mencapai kinerja yang cukup baik (yaitu pengguna senang dan backend saya tidak merasa ngeri), apakah saya perlu memahami teori tentang kompleksitas algoritmik?

Itu tergantung pada apa yang Anda maksud dengan aplikasi bisnis "khas". Dalam banyak kasus, terutama sistem informasi sederhana seperti CRUD, jawabannya adalah tidak. Untuk ini Anda akan "hanya" (kadang-kadang sebenarnya sulit) harus dapat melacak kemacetan kinerja: apakah saya kehilangan indeks di database saya? Apakah saya mengirim terlalu banyak data melalui jaringan? Apakah saya memiliki jam tangan $ seribu di front-end angular.js saya? Ini tentang membangun arsitektur suara, mengetahui teknologi Anda menumpuk dengan baik, dan menghindari tidak masuk akal. Anda dapat mencapainya jika Anda seorang perajin yang baik, tidak harus seorang ilmuwan komputer. Cara lain untuk mengatakannya adalah bahwa orang-orang yang membangun pengoptimal permintaan Oracle berurusan dengan hal-hal kompleksitas algoritmik, Anda hanya perlu menggunakan dengan benar apa yang mereka berikan kepada Anda.

Sekarang ada pengecualian. Jika kita berbicara tentang big data atau pembelajaran mesin, Anda perlu tahu apa yang Anda lakukan dan tidak hanya menggunakan algoritma default yang tersedia untuk Anda. Bahkan di ujung depan, jika Anda mulai membangun visualisasi data tingkat lanjut beberapa di antaranya dapat menyiratkan biaya kompleksitas non linier (misalnya grafik gaya-tata letak).

Saat ini pengecualian ini menjadi semakin umum dan pasar cukup kering ketika Anda mencari orang yang dapat menanganinya. Jadi: ya, Anda bisa sukses tanpa latar belakang ilmu komputer, tetapi Anda akan lebih lagi dengan itu.

Responden lain telah membahas sebagian besar poin dasar, tetapi untuk tugas-tugas yang dapat diparalelkan, perangkat lunak yang tidak efisien menyebabkan peningkatan biaya perangkat keras dalam bentuk lebih banyak server, yang menggunakan lebih banyak daya dan membutuhkan lebih banyak ruang dan pemeliharaan.