Karena ada perbedaan besar antara mengoptimalkan kinerja dan mematikan sepenuhnya keselamatan
Dengan mengurangi jumlah GC, kerangka kerja mereka lebih responsif dan dapat berjalan (mungkin) lebih cepat. Sekarang, mengoptimalkan pengumpul sampah tidak berarti mereka tidak pernah melakukan pengumpulan sampah. Itu hanya berarti mereka melakukannya lebih jarang, dan ketika mereka melakukannya, itu berjalan sangat cepat. Jenis optimasi tersebut meliputi:
- Meminimalkan jumlah objek yang pindah ke ruang selamat (yaitu yang bertahan setidaknya satu pengumpulan sampah) dengan menggunakan benda-benda kecil yang dibuang. Objek yang dipindahkan ke ruang selamat lebih sulit untuk dikumpulkan dan pengumpulan sampah di sini kadang-kadang menyiratkan seluruh JVM.
- Jangan mengalokasikan terlalu banyak objek untuk memulai. Ini bisa menjadi bumerang jika Anda tidak hati-hati, karena objek generasi muda sangat murah untuk dialokasikan dan dikumpulkan.
- Pastikan bahwa objek baru menunjuk ke yang lama (dan bukan sebaliknya) sehingga objek muda mudah dikumpulkan, karena tidak ada referensi kepada mereka yang akan menyebabkan mereka disimpan
Ketika Anda mengabaikan kinerja, Anda biasanya mencari beberapa "hot spot" yang sangat spesifik sambil mengabaikan kode yang tidak sering berjalan. Jika Anda melakukannya di Jawa, Anda dapat membiarkan pengumpul sampah tetap merawat sudut-sudut gelap itu (karena itu tidak akan membuat banyak perbedaan) sambil mengoptimalkan dengan sangat hati-hati untuk area yang berjalan dalam loop ketat. Jadi Anda dapat memilih di mana Anda mengoptimalkan dan di mana Anda tidak, dan dengan demikian Anda dapat memfokuskan upaya Anda di tempat yang penting.
Sekarang, jika Anda mematikan pengumpulan sampah sepenuhnya, maka Anda tidak dapat memilih. Anda harus membuang setiap objek secara manual . Metode itu dipanggil paling banyak sekali sehari? Di Jawa, Anda dapat membiarkannya, karena dampak kinerjanya dapat diabaikan (mungkin OK untuk membiarkan GC penuh terjadi setiap bulan). Di C ++, Anda masih membocorkan sumber daya, jadi Anda harus berhati-hati bahkan dari metode yang tidak jelas itu. Jadi, Anda harus membayar harga untuk manajemen sumber daya di setiap bagian aplikasi Anda, sementara di Jawa Anda dapat fokus.
Tapi itu semakin buruk.
Bagaimana jika Anda memiliki bug, katakanlah di sudut gelap aplikasi Anda yang hanya diakses pada hari Senin di bulan purnama? Jawa memiliki jaminan keamanan yang kuat. Ada sedikit atau tidak ada "perilaku tidak terdefinisi". Jika Anda menggunakan sesuatu yang salah, Pengecualian dilempar, program Anda berhenti, dan tidak ada kerusakan data terjadi. Jadi Anda cukup yakin bahwa tidak ada yang salah dapat terjadi tanpa Anda sadari.
Tetapi dalam sesuatu seperti D, Anda dapat memiliki akses pointer buruk, atau buffer overflow, dan Anda dapat merusak memori Anda, tetapi program Anda tidak akan tahu (Anda mematikan keselamatan, ingat?) Dan akan terus berjalan dengan salahnya data, dan melakukan beberapa hal yang cukup jahat dan merusak data Anda, dan Anda tidak tahu, dan semakin banyak korupsi terjadi, data Anda semakin salah, dan kemudian tiba-tiba rusak, dan itu dalam aplikasi yang sangat penting, dan beberapa kesalahan terjadi dalam perhitungan roket, sehingga tidak berfungsi, dan roket meledak, dan seseorang mati, dan perusahaan Anda ada di halaman depan setiap surat kabar dan bos Anda mengarahkan jarinya ke Anda mengatakan "Kamu adalah insinyur yang menyarankan agar kami menggunakan D untuk mengoptimalkan kinerja, mengapa Anda tidak memikirkan keselamatan?". Dan itu salahmu. Kamu membunuh orang-orang itu dengan upaya bodohmu dalam kinerja.
OKE, OKE, sebagian besar waktu itu jauh kurang dramatis dari itu. Tetapi bahkan aplikasi penting bisnis atau hanya aplikasi GPS atau, katakanlah, situs web layanan kesehatan pemerintah dapat menghasilkan konsekuensi yang cukup negatif jika Anda memiliki bug. Menggunakan bahasa yang mencegah mereka sepenuhnya atau gagal-cepat ketika mereka terjadi biasanya adalah ide yang sangat bagus.
Ada biaya untuk mematikan pengaman. Menjadi asli tidak selalu masuk akal. Kadang jauh lebih mudah dan lebih aman untuk hanya mengoptimalkan sedikit bahasa yang aman untuk masuk semua untuk bahasa di mana Anda dapat menembak diri sendiri dalam waktu besar. Kebenaran dan keamanan dalam banyak kasus mengalahkan beberapa nano detik yang akan Anda hilangkan dengan menghilangkan GC sepenuhnya. Disruptor dapat digunakan dalam situasi itu, jadi saya pikir LMAX-Exchange membuat panggilan yang tepat.
Tapi bagaimana dengan D khususnya? Anda memiliki GC jika Anda ingin sudut-sudut gelap, dan subset SafeD (yang saya tidak tahu sebelum mengedit) menghapus perilaku yang tidak terdefinisi (jika Anda ingat untuk menggunakannya!).
Nah dalam hal ini pertanyaan sederhana tentang kedewasaan. Ekosistem Jawa penuh dengan alat yang ditulis dengan baik dan perpustakaan yang matang (lebih baik untuk pengembangan). Lebih banyak pengembang yang tahu Java daripada D (lebih baik untuk pemeliharaan). Memilih bahasa baru dan tidak terlalu populer untuk sesuatu yang sama pentingnya dengan aplikasi finansial bukanlah ide yang bagus. Dengan bahasa yang kurang dikenal, jika Anda memiliki masalah, sedikit yang dapat membantu Anda, dan perpustakaan yang Anda temukan cenderung memiliki lebih banyak bug karena mereka terpapar pada lebih sedikit orang.
Jadi poin terakhir saya masih berlaku: jika Anda ingin menghindari masalah dengan konsekuensi yang mengerikan, tetaplah dengan pilihan yang aman. Pada titik ini dalam kehidupan D, pelanggannya adalah perusahaan baru kecil yang siap mengambil risiko gila. Jika masalah dapat menelan biaya jutaan, Anda lebih baik tinggal lebih jauh dalam kurva lonceng inovasi .