Keberhasilan yang Absurd
(marginalia.nu)- Marginalia Search, melalui perubahan terbaru, mengurangi kebutuhan RAM hingga separuh dan secara signifikan menurunkan beban operasional yang sebelumnya mengharuskan mesin pencari dimatikan saat upgrade
- Gangguan muncul dalam proses peralihan indeks setelah rilis terbaru, dan struktur yang menghapus database URL saat upgrade menyebabkan offline dalam waktu lama
- Penyimpanan URL berubah dari struktur yang berpusat pada tabel dan indeks MariaDB raksasa menjadi satu database SQLite dengan ID URL 64-bit yang dibuat oleh proses
- Pembuatan indeks terbalik beralih dari lexicon untuk term ID padat dan penulisan acak berskala besar ke metode membuat preindex kecil lalu menggabungkannya
- Struktur baru memungkinkan backup file yang bisa dipulihkan dalam beberapa jam bahkan saat deployment buruk, serta memudahkan penggunaan ulang hasil pemrosesan data besar yang jarang berubah seperti Wikipedia
Kondisi operasional mesin pencari yang berubah hanya dalam seminggu
- Marginalia Search mengurangi beberapa masalah jangka panjang sekaligus lewat coding selama satu minggu
- Kebutuhan RAM mesin pencari turun hingga separuh
- Kebutuhan untuk membuat sistem offline saat upgrade hilang
- Batas keras jumlah dokumen yang dapat diindeks dihapus
- Batas lunak jumlah kata kunci yang dapat dimasukkan dalam korpus naik 4 kali lipat
- Tujuan jangka panjangnya adalah menjaga agar sistem tetap dapat dijalankan pada hardware berkinerja rendah, dan perubahan kali ini merupakan peningkatan yang lebih besar dibanding perbaikan sebelumnya yang membuat mesin pengembangan dengan RAM 32GB terasa lega
Struktur upgrade lama yang memperparah gangguan
- Marginalia Search hampir satu minggu berada dalam keadaan offline karena masalah pada rilis terbaru
- Penyebab langsungnya adalah rangkaian masalah skalabilitas yang relatif kecil, tetapi proses yang biasanya memakan 1 hari, atau 2–3 hari jika bermasalah, harus diulang beberapa kali
- Sebagian besar restart terjadi karena kekurangan RAM
- Alasan gangguan sangat terasa oleh pengguna adalah karena sistem harus dibuat offline saat peralihan indeks
- Dalam struktur lama, database URL dihapus saat upgrade, dan pekerjaan menyisipkan serta memperbarui baris dengan cepat pada tabel yang mendekati 1 miliar baris menjadi bottleneck
- Proses yang memuat data baru menggunakan banyak RAM
- Sulit menjalankannya bersamaan dengan layanan indeks yang menggunakan RAM dengan cara serupa
- Primary key berupa integer 32-bit memiliki batas yang sulit melewati 2 miliar
Desain ulang database URL
- Database URL adalah komponen lama dalam mesin pencari, dan keputusan desain awalnya tidak lagi cocok dengan struktur sistem saat ini
- Di intinya ada dua tabel yang hanya digunakan saat memuat indeks baru dan hanya dibaca melalui lookup primary key
- Tabel URL memberikan ID numerik unik untuk setiap URL
- Tabel PAGE_DATA berisi informasi seperti judul dan deskripsi tautan yang diindeks
- Ada indeks tambahan untuk menjaga keunikan path di dalam domain, tetapi ukurannya sangat besar dibanding perannya
- Struktur baru menggabungkan dua tabel menjadi satu database SQLite dengan satu tabel, menyerahkan pembuatan ID unik ke proses loader, dan menangani daftar URL yang tidak diindeks sebagai tabel terpisah
- Penggunaan MariaDB dan SQLite secara bersamaan bukan pilihan yang lazim, tetapi kedua penyimpanan ini menangani kebutuhan yang berbeda
- Sistem membutuhkan pandangan dunia persisten yang relatif kecil
- Pada saat yang sama, status berskala terabyte harus bisa diganti seperti plug-and-play
- Tabel DOCUMENT dan DOMAIN berhubungan secara longgar lintas database, tetapi join sebenarnya tidak diperlukan
- Dalam situasi bencana, bagian penting dari tabel DOMAIN dapat direkonstruksi dari tabel DOCUMENT
Membuat ID URL 64-bit tanpa indeks
- Tabel URL lama menggunakan ID 32-bit, dan kondisi yang mendekati integer overflow adalah masalah skalabilitas yang sudah diketahui
- Salah satu alasan database URL dihapus juga untuk mencegah kolom ID meluap
- Counter sederhana saja tidak dapat menangani URL yang berulang, dan pendekatan menyimpan koleksi semua URL yang pernah terlihat di memori juga harus dihindari
- Metode baru tidak membiarkan database menetapkan ID, melainkan menyusun ID 64-bit secara langsung
- 26 bit bawah digunakan sebagai nomor urut
- Bit 26–56 digunakan sebagai ID dokumen
- Bit paling atas dicadangkan untuk trik pengurutan indeks
- Susunan ini memungkinkan sekitar 67 juta dokumen per domain
- Sekitar 10 kali ukuran Wikipedia bahasa Inggris
- Domain diizinkan hingga 2 miliar
- Hampir 100 kali jumlah domain yang pernah dilihat Marginalia sebagai referensi dari mana pun di web
- Tanggung jawab konsistensi data berpindah dari database ke proses pembuatan data, tetapi biaya untuk menegakkannya di sisi tersebut jauh lebih rendah
Beban memori yang dikurangi oleh desain ulang URL
- Dengan menghapus indeks raksasa dan tabel besar yang mencampur data URL hot dan cold, server MariaDB tidak lagi membutuhkan RAM 36GB
- Data hot yang tersisa di MariaDB paling banyak berada di kisaran beberapa ratus MB, dan RAM yang perlu dialokasikan ke server kemungkinan besar tidak lebih dari 2GB
- Data SQLite tetap membutuhkan indeks untuk primary key, tetapi bagian indeks yang benar-benar hot diperkirakan kurang dari 1GB
- Jumlah data yang diindeks berkurang satu orde digit
- Target indeks hanya satu long 64-bit
- Tidak ada constraint unique tambahan
- Karena output loader menjadi sekumpulan file, backup otomatis menjadi lebih mudah dibuat
- Jika terjadi deployment buruk, pemulihan dapat dilakukan dalam beberapa jam, bukan hampir satu minggu seperti sebelumnya
Bottleneck pembuatan indeks terbalik
- Loader menghasilkan database URL dan jurnal berpusat dokumen
(document, words[]), sementara pencarian membutuhkan indeks yang mentransposisikannya menjadi bentuk(word, documents[]) - Metode lama menggunakan lexicon yang memetakan string kata kunci ke term ID yang padat
- Kata pertama mendapat ID 0, kata berikutnya mendapat ID 1
- String dipetakan ke long melalui hash 64-bit
- Strukturnya pada dasarnya adalah open hashmap long-to-int
- Struktur ini mudah penuh saat skalanya membesar
- Java tidak mengizinkan array yang melebihi 2 miliar elemen
- Implementasi yang digunakan sudah mentok di kisaran 1 miliar elemen
- Pada 1 miliar entri, RAM yang digunakan 12GB
- index service yang sedang berjalan menggunakan RAM 60GB, dan sebagian besarnya adalah memori off-heap
- Ukuran on-heap yang melampaui 32GB juga menjadi masalah karena menyulitkan penggunaan CompressedOOPs
Amplifikasi tulis pada algoritme indeks terbalik lama
- Algoritme lama mencari word ID terbesar, membuat array counts sebesar itu, lalu menghitung posisi dokumen per kata dan menulis data dokumen ke file memory-mapped
- Cara ini membutuhkan lexicon karena mengasumsikan domain word ID terisi padat
- Bottleneck yang lebih besar adalah proses menulis sekitar 1TB data ke file memory-mapped dalam urutan yang hampir sepenuhnya acak
- SSD menangani akses acak dengan baik untuk pembacaan, tetapi pada penulisan kecil muncul masalah write amplification
- SSD harus menghapus dan menulis ulang seluruh page meski hanya memperbarui satu byte di disk
- Ada cache yang mengumpulkan penulisan berdekatan, tetapi tidak efektif untuk penulisan acak berskala terabyte
- Saat menulis 1TB, drive berada dalam situasi menulis sekitar 0,5PB
- Sebagai mitigasi sementara, ada
RandomWriteFunnel- Penulisan terlebih dahulu dibagi ke bucket file kecil
- Setelah itu file besar ditulis secara berurutan
- Lebih baik daripada cara awal, tetapi tetap sangat lambat
Membuat preindex kecil lalu menggabungkannya
- Pembuatan indeks terbalik baru menggunakan cara membuat beberapa indeks kecil yang seluruh datanya masuk ke memori, lalu menggabungkannya
- Penggabungan daftar terurut cepat dan merupakan pekerjaan yang cocok bahkan untuk hard disk mekanis
- Dengan cara ini, lexicon tidak lagi diperlukan
- Hash string 64-bit dapat langsung digunakan sebagai term ID
- Masalah awal yang muncul adalah input yang terkompresi dan cara penggabungan indeks
- Alih-alih membaca sebagian input terkompresi dengan cepat, dibuat beberapa file kecil lalu dibaca satu per satu
- Alih-alih menggabungkan setelah indeks dibuat, data digabungkan sebelum indeks dibuat
- Abstraksi baru
preindexterdiri dari array ID kata, array count, dan array data dokumen - Karena inputnya kecil, sebagian besar preindex dapat dibuat di RAM, di-commit ke disk saat dibuat, lalu tahap penggabungan berikutnya membuat preindex final
- Preindex final diubah menjadi indeks terbalik dengan menambahkan tabel words dan indeks btree statis ke setiap document block seperti sebelumnya, dan proses ini relatif cepat
Perubahan pada operasi dan penggunaan ulang data
- Penghapusan lexicon menurunkan kebutuhan RAM, dan pembuatan indeks terbalik baru lebih cepat daripada algoritme lama
- Lexicon lama membuat dialek tersendiri untuk setiap kumpulan data yang diproses
- Kata yang sama bisa mendapat ID tertentu pada satu eksekusi, dan ID berbeda pada eksekusi lain
- Karena itu, semua data harus diproses sekaligus
- Dengan meninggalkan lexicon, kumpulan data yang berbeda dapat digabungkan
- Hasil pemrosesan data besar yang jarang berubah seperti Wikipedia dapat digunakan ulang dan digabungkan dengan data indeks yang lebih sering berubah
- Perubahan ini mengurangi hampir semua masalah skalabilitas dan ketidaknyamanan operasional yang diketahui, serta membuka kondisi untuk meninjau lebih banyak efek samping
2 komentar
Marginalia - mesin pencari DIY independen
Komentar Hacker News
Rasanya benar-benar menyenangkan melihat kisah sukses seperti ini dari proyek yang berjalan ke arah yang benar-benar berlawanan dengan dunia selebihnya
Saya ingin menyebutnya Engildification, dan hal seperti ini perlu lebih banyak
Saya juga suka tulisan Sleeping At Night, dan bersama tulisan terbaru “Lie Still in Bed”, itu terlihat seperti opsi yang sangat sederhana untuk mencoba memperbaiki masalah pelatihan tidur
Mesin pencari Marginalia baru-baru ini digarap penuh waktu oleh penulisnya, dan sejauh yang saya tahu ukuran timnya 1 orang, jadi paling jauh dari risiko enshittification. Justru pada skala seperti inilah permata tercipta, dan kreativitas, keunikan, serta visi bersinar
Komentar ini disponsori oleh perkumpulan “berhenti kerja kantoran dan bekerjalah secara independen”
Ia memangkas konsumsi sumber daya hingga setengahnya, menjadi lebih produktif dari sebelumnya di layar yang lebih kecil, dan tidur nyenyak seperti batang kayu pada malam hari
Tautan bagi yang tertarik: https://www.marginalia.nu/log/86-sleep/
Sebagai catatan, mesin pencari berbayar Kagi, yang mungkin juga pernah Anda lihat di Hacker News, memakai Marginalia sebagai salah satu sumber datanya
https://help.kagi.com/kagi/search-details/search-sources.htm...
Jika memakai lensa “non-commercial”, hasil seperti ini akan diprioritaskan bersama hasil dari indeks Kagi sendiri dan beberapa sumber independen
Membaca tulisan ini membuat saya berpikir bahwa manusia mungkin memang makhluk yang sulit menciptakan sesuatu yang luar biasa tanpa batasan artifisial
Alasan Marginalia luar biasa efisien adalah karena Victor sengaja membatasi hardware eksekusi dan kapasitas memorinya
Kalau sekadar menambahkan 32GiB lagi, mungkin akan tetap berjalan untuk sementara, tetapi desain yang tidak efisien akan tetap ada, dan nanti masalah yang sama bisa meledak ketika kondisinya sudah lebih kompleks sehingga lebih sulit diperbaiki
Jika asumsi ini benar, itu juga menjelaskan mengapa software masa kini membengkak, lambat, dan penuh bug. Karena masing-masing software secara terpisah hampir tidak pernah menyentuh batasnya, setiap bagian boleh saja tidak efisien, tetapi dengan M2 Pro modern dan koneksi berskala GiB, titik masalahnya terus saja terlampaui
Kesimpulannya mungkin bahwa membatasi diri sendiri dalam jangka panjang lebih baik bagi diri sendiri dan semua orang
Di banyak aplikasi, menghabiskan begitu banyak waktu untuk optimasi kecil memang tidak masuk akal. Kalau RAM 32GiB bisa ditambahkan ke server dengan biaya di bawah 50 dolar, dibandingkan memakai lebih dari 40 jam developer dengan tarif minimal 20 dolar per jam, dari sudut pandang bisnis jawabannya jelas. Selain itu, websitenya sempat down sepanjang minggu, dan itu saja sudah bisa mematikan sebagian besar bisnis
Para teknisi menyukai penggalian sedalam ini, sampai ingin mengoptimalkan kode kecil secara mikro selama bertahun-tahun, tetapi mencukur yak tanpa akhir tidak menghasilkan uang. Kalau kode hanya berjalan di segelintir mesin, biasanya itu tidak sepadan. Optimasi seperti ini juga sering berakhir menjadi kode yang lebih sulit dipelihara
Menurut saya software bloat pada aplikasi yang berjalan di perangkat pengguna saat ini banyak berasal dari ketidaksesuaian antara perangkat developer dan perangkat pengguna. Developer membutuhkan workstation berperforma tinggi untuk bekerja dan juga melakukan pengujian dasar di sana, sementara pengguna menjalankannya di perangkat yang lima tahun lalu saja sudah kelas menengah ke bawah
Sulit menjual ke manajer bahwa “kita bisa menghemat memori 150MB”, tetapi “kalau menghemat memori 150MB, performa aplikasi untuk 10% pengguna naik dari buruk sekali menjadi nyaris layak pakai” bisa dijual
Dulu software memang dibuat seperti itu. Karena itu, bahkan mesin seperti Pentium 1 pun bisa menjalankan sistem operasi dengan baik yang memiliki sebagian besar hal yang kita harapkan hari ini. Sebaliknya sekarang, bahkan smartphone yang secara harfiah memiliki sumber daya sekitar seribu kali lebih besar di semua sumbu pun tersendat saat menggulir halaman web. Tim Word 95 selalu berhadapan dengan batasan dan kompromi performa, dan hasilnya jelas: berfungsi atau tidak berfungsi
Kalau mereka hanya menambahkan lebih banyak RAM, mereka masih akan terjebak dalam desain yang inferior, dan segera harus membeli RAM lebih banyak lagi. Hal mengejutkan dari perubahan ini bukan hanya berkurangnya penggunaan sumber daya, tetapi karena RAM yang longgar membuat disk cache bertambah sehingga sistem menjadi lebih mampu dan lebih cepat
[1] Misalnya, ini berjalan di satu Pi, dan karena tidak mengizinkan pembaruan, jauh lebih cepat daripada Wikipedia yang sedang beroperasi: https://encyclopedia.marginalia.nu/article/Hacker_News
Mungkin itulah sebabnya komputer lama terasa menyenangkan, dan game lama bisa begitu hebat
Mungkin ini berkaitan dengan kompleksitas sistem yang kita tangani. Jika sumber daya seperti RAM, ruang fisik, makanan, bahan, waktu, dan uang terbatas, kita harus merencanakan cara memakainya, dan mau tidak mau menjadi lebih cerdas
Jika sumber daya praktis tak terbatas, kita bisa membuat apa pun sesuka hati, tetapi kebutuhan untuk peduli pada keadaan akhirnya berkurang. Tinggal mulai saja, lalu lihat saat sudah berjalan
Saya bukan gamer sejati, tetapi selalu kagum pada kemampuan manusia memasukkan begitu banyak emosi, petualangan, dan jam hiburan ke dalam kartrid ROM beberapa KB/MB. ROM Ocarina Of Time ukurannya hanya kira-kira sebesar 8 foto terbaru yang saya ambil dengan iPhone
Raspberry Pi 2 dapat memproses lebih dari 4 miliar instruksi Dhrystone per detik, dan Pi 4 lebih dari 10 miliar per detik
Tentu saja, menurut standar modern, SABRE pertengahan 1970-an cukup mendasar untuk sistem inti sebuah maskapai, tetapi secara teori satu Pi 2 saja bisa menjalankan lebih dari 100 sistem maskapai yang disederhanakan secara bersamaan
Program modern sangat jauh dari optimal. Kecuali untuk kasus yang banyak operasi matematikanya, peningkatan 1000x atau 10000x pun mungkin
Menurut saya Microsoft sangat mengalami masalah ini. Laptop seharga 3000 dolar dari 5 tahun lalu pun menjadi lambat sampai sulit diterima jika menjalankan panggilan Teams, beberapa aplikasi Office, dan browser dengan 30 tab secara bersamaan
Kalau diuji satu per satu, semuanya baik-baik saja saat hanya satu yang berjalan, tetapi orang sungguhan tidak memakainya seperti itu
Mungkin solusinya adalah batasan artifisial berupa pembatasan waktu eksekusi pada hardware yang didefinisikan jelas, lalu menaikkan batas itu hanya setelah keputusan eksplisit
Namun saya hanya menulis software bisnis yang dari sisi performa berujung pada “jangan melakukan hal bodoh ke database, dan untuk sisanya jangan pedulikan karena pelanggan tidak membayar untuk kekhawatiran itu”, jadi bisa saja saya sepenuhnya salah sasaran
Saya selalu senang setiap kali pembaruan marginalia.nu muncul. Anda adalah pengguna yang berharga di situs ini, dan saya harap terus mempostingnya
Terima kasih. Saya sedang mengerjakan proyek hobi mesin pencari, tetapi entah kenapa selama ini terus mencari variasi “Magnolia”. Nama Marginalia sulit melekat di ingatan saya. Saat ini saya sedang memahami Searx
Saya penasaran apakah Marginalia mendukung pencarian dengan filter waktu seperti sehari terakhir atau minggu lalu. Dari kata kunci khususnya, sepertinya parameter pencarian hanya menerima basis tahun
year>2005 (beta) dokumen tampaknya diterbitkan setelah 2005
year=2005 (beta) dokumen tampaknya diterbitkan pada 2005
year<2005 (beta) dokumen tampaknya diterbitkan sebelum 2005
Filter tahun juga cukup kasar, dan sangat sulit menentukan tanggal sebagian besar halaman web secara akurat
Saya penasaran apakah pernyataan “setiap kali SSD memperbarui satu byte di suatu tempat pada disk, ia harus menghapus dan menulis ulang seluruh page” benar-benar berlaku untuk SSD
Pada flash mentah, tidak begitu. Itu bisa dilakukan jika menimpa nilai “kosong” all-ones, atau hanya mengubah 1 menjadi 0. Penulisan memang beberapa orde magnitudo lebih lambat daripada pembacaan, tetapi juga beberapa orde magnitudo lebih cepat daripada penghapusan, dan hanya penghapusan yang dihitung dalam anggaran keausan
Kalau controller SSD tidak memanfaatkan hal ini, kedengarannya seperti gol bunuh diri. Namun kalau bagian dalamnya memang log-structured, mungkin saja tidak bisa
Dulu saya pernah menulis driver untuk beberapa chip flash populer, dan semua chip yang saya tangani saat itu hanya memakai I/O berbasis page berukuran tetap untuk baca maupun tulis
Karena SSD adalah kumpulan chip, saya memperkirakan tiap chip di dalam SSD juga hanya mendukung I/O page berukuran tetap
Biasanya controller memakai berbagai teknik seperti overprovisioning, buffering, dan penataan ulang penulisan untuk menghindari pola terburuk seperti ini, tetapi tetap ada batasnya
Unit terkecil yang bisa ditulis pada SSD adalah page, dan unit terkecil yang bisa dihapus adalah block yang terdiri dari beberapa page
Jadi meskipun operasi tulis hanya memengaruhi 1 byte di dalam sebuah page, SSD tidak bisa menghapus byte itu saja. Namun itu juga tidak berarti harus selalu menghapus seluruh block
SSD dapat melakukan operasi semacam “read-modify-write”. Ia membaca seluruh page yang berisi byte yang berubah ke buffer cache SSD, memodifikasi hanya byte tersebut di cache page, lalu menghapus block baru yang kosong, menulis page yang sudah dimodifikasi dari cache ke block baru, dan memperbarui tabel pemetaan FTL agar menunjuk ke page yang sudah diperbarui di block baru
Jadi meskipun hanya 1 byte yang berubah, page tetap harus ditulis ulang. Namun penghapusan seluruh block dapat dihindari sampai banyak page di dalamnya ikut dimodifikasi
Saat penulisan terjadi, page berpindah di dalam perangkat fisik. Drive itu sendiri mempertahankan peta yang berisi alamat mana dipakai untuk apa, bagaimana kondisi kesehatannya, dan sebagainya. Ini semacam penyimpanan sparse
Ada juga perintah seperti TRIM, pemeliharaan berkala, dan garbage collection
Dalam praktiknya, ketika menulis ke drive yang belum penuh, drive akan mencari page untuk menaruh data, memeriksa apakah ada data di sana, melakukan read/modify/write jika perlu, menentukan di mana data akan ditulis, lalu menulisnya. Karena wear leveling, besar kemungkinan data tidak kembali ke lokasi semula
Benar bahwa controller melakukan langkah-langkah yang jauh lebih kompleks demi performa. Itulah sebabnya drive baru yang kosong bekerja lebih baik untuk sementara waktu, dan drive lama yang penuh tanpa page cadangan bisa benar-benar melambat
Sebagai konteks, saya dulu adalah lead engineer untuk akselerator flash memory-mapped dengan koherensi cache. Kami membuat drive dapat dipetakan dengan sangat efisien dari Linux user space, tetapi pada akhirnya untuk beberapa waktu kami menyerah pada model pemrograman yang “mudah”, yang membuatnya terlihat seperti hard drive biasa lagi
Ini mengingatkan saya bahwa atasan saya di Mojeek mungkin juga menempuh jalur yang sangat mirip. Tulisan ini sangat bersinggungan dengan percakapan-percakapan lama
Mojeek dimulai pada 2004, dan sebagian besar kerangkanya dibuat oleh satu developer, yang membangun hampir seluruh sistem information retrieval dan infrastrukturnya
Kendala pendanaan dan hardware, keputusan ID 32-bit vs 64-bit, sharding, kecepatan update—semuanya terdengar sangat akrab
Saya juga teringat “Google dance” pada masa Google dulu. Saat itu hasil pencarian diperbarui sebulan sekali, sedangkan sekarang berfluktuasi setiap hari. Semuanya adalah proses evolusi, dan menyenangkan melihat Marginalia menawarkan sudut pandang lain tentang web di luar Big Tech
Enak dibaca
Banyak orang menganggap optimasi sebagai ilmu hitam yang dalam, tetapi sebagian besar justru lebih mudah daripada perbaikan bug biasa. Perlakukan saja penggunaan resource yang berlebihan persis seperti bug
Menurut saya, kebanyakan bug yang mudah direproduksi tidak membutuhkan sihir untuk diperbaiki. Jika bug bisa “ditusuk-tusuk”, biasanya bug itu bisa diklasifikasikan, dan cacat desain yang jarang pun umumnya cepat terlihat begitu bisa direproduksi
Software yang performanya tidak pernah dilihat secara kritis itu seperti software yang punya ratusan bug yang mudah direproduksi tetapi tidak pernah di-debug siapa pun. Anda bisa memangkasnya satu per satu cukup lama sebelum menemui yang benar-benar sulit
Menurut saya sikap seperti ini lebih merupakan peninggalan masa ketika orang menyesuaikan alamat target branch agar tiba tepat saat drum head mencapai posisi ketika CPU membutuhkan instruksi. Pada masa resource sangat terbatas, semuanya ditulis manual dalam assembly, dan lokasi memori global bisa memiliki arti berbeda tergantung tahap program, sudah ada orang-orang yang sangat pintar meninjau performa secara kritis, sehingga kita harus menemukan apa yang tidak mereka temukan. Pada kode modern, itu jarang terjadi
Jika bug bisa direproduksi dengan mengirim request X ke service Y, tinggal perkecil test case sedikit demi sedikit sampai pelakunya ditemukan
Optimasi sering kali merupakan masalah arsitektur. Memang ada kasus ketika kita menyalin sesuatu padahal buffer bisa digunakan ulang, tetapi hal-hal seperti itu cepat habis, dan profiler akan memberi tahu informasi yang diperlukan
Peningkatan performa besar sering kali datang dari mengubah seluruh alur data dan menghilangkan bagian yang signifikan, sehingga kode melakukan pekerjaan yang diperlukan dengan langkah sesedikit mungkin
Saya penasaran mengapa memilih SQLite dan bukan key-value store. Kalau hanya ingin membaca berdasarkan ID dan tidak membutuhkan kolom lain, database relasional tampaknya tidak diperlukan
SQLite punya keunggulan berupa satu file tunggal. Jadi bisa melakukan hal-hal menarik seperti menyalin atau membagikannya
Saya suka karena ini satu lagi contoh bahwa keterbatasan melahirkan inovasi. Inovasi lebih sering ditemukan dari batasan daripada dari kelimpahan