Hentikan kebocoran memori Monosnap — beralih dalam 60 detik

Kebocoran bukan pada komputer Anda

Jika Anda bertanya-tanya apakah itu mesin Anda — driver lama, keanehan Windows 11, tab Chrome yang tidak terkendali — bukan itu masalahnya. Kebocoran ada di dalam Monosnap dan sudah berlangsung bertahun-tahun. Cari r/monosnap dan Anda akan menemukan banyak utas yang menjelaskan pola yang sama.

Inilah yang terjadi di balik layar. Setiap kali Monosnap menangkap suatu wilayah, ia mengalokasikan *frame buffer* yang cukup besar untuk menampung data piksel mentah. Untuk layar 2560 x 1440, itu sekitar 14 MB. Ketika editor ditutup, *buffer* tersebut seharusnya dilepaskan kembali ke OS. Di Monosnap, seringkali tidak demikian — *buffer* tersebut dipertahankan oleh *heap* *renderer* Electron, menunggu proses *garbage-collection* yang tidak pernah berjalan atau berjalan terlalu lambat. Selama hari kerja dengan 40+ tangkapan, *buffer* yang dipertahankan menumpuk menjadi ratusan megabyte RAM 'hantu'.

Solusinya adalah aplikasi yang berbeda

Arsitektur Monosnap mengaitkan kebocoran dengan Electron itu sendiri, dan memperbaikinya akan membutuhkan penulisan ulang *capture pipeline*. Penulisan ulang itu belum terjadi dalam lima tahun. Solusi praktisnya adalah alat yang dirancang tanpa masalah tersebut sejak awal.

Maxisnap dibangun di atas PyQt6 dan dikompilasi dengan PyInstaller menjadi satu *executable* Win32. Tidak ada proses Chromium. Setiap tangkapan mengalokasikan QImage, editor mereferensikannya, dan ketika jendela ditutup, referensi tersebut dilepaskan dan memori segera kembali ke OS — karena model kepemilikan PyQt dan *reference counting* Python keduanya melepaskan dengan cepat daripada menunggu *generational GC*.

Secara empiris: Maxisnap dalam keadaan *idle* saat diluncurkan sekitar 50 MB. Setelah 72 jam berjalan terus-menerus dengan tangkapan reguler, ukurannya masih sekitar 50 MB. Grafik di atas berasal dari log aktual.