Stoppa Monosnaps minnesläcka — byt på 60 sekunder

Läckan är inte din dator

Om du har undrat om det är din maskin — en gammal drivrutin, Windows 11-konstigheter, en skenande Chrome-flik — så är det inte det. Läckan finns inuti Monosnap och har funnits där i åratal. Sök r/monosnap och du hittar tråd efter tråd som beskriver samma mönster.

Här är vad som händer under huven. Varje gång Monosnap fångar ett område allokerar det en rambuffert som är tillräckligt stor för att hålla råa pixeldata. För en 2560 x 1440 skärm är det ungefär 14 MB. När redigeraren stängs bör dessa buffertar släppas tillbaka till operativsystemet. I Monosnap görs det ofta inte — de behålls av Electron-renderarens heap, i väntan på en skräpsamlingspass som antingen aldrig körs eller körs för sent. Under en arbetsdag med 40+ skärmdumpar ackumuleras de behållna buffertarna till hundratals megabyte av fantom-RAM.

Lösningen är en annan app

Monosnaps arkitektur kopplar läckan till Electron självt, och att patcha det skulle kräva att man skriver om fångstpipelinen. Den omskrivningen har inte skett på fem år. Den praktiska lösningen är ett verktyg som designades utan problemet från första början.

Maxisnap är byggt på PyQt6 och kompilerat med PyInstaller till en enda Win32-körbar fil. Det finns ingen Chromium-process. Varje skärmdump allokerar en QImage, redigeraren refererar till den, och när fönstret stängs släpps referensen och minnet återgår omedelbart till operativsystemet — eftersom PyQt:s ägarmodell och Pythons referensräkning båda släpper ivrigt snarare än att vänta på en generations-GC.

Empiriskt: Maxisnap i viloläge vid start är runt 50 MB. Efter 72 timmars kontinuerlig körning med regelbundna skärmdumpar är det fortfarande runt 50 MB. Diagrammet ovan är från faktiska loggar.