Hoe de verwijderlijst van Mole direct bij een klik verschijnt

Als je op de verwijderpagina van Mole op een app klikte, bleef de rechterkant even leeg, verscheen daarna "Scannen", en pas na een halve tot een hele seconde kwamen de restbestanden in beeld. Xcode had bij elke klik drie à vier seconden nodig, ChatGPT zes, en scrollen door de uitgeklapte lijst van ChatGPT haperde. Ik wilde zien waar die tijd echt bleef, en keek meteen hoe een paar opensource-verwijderprogramma's hetzelfde probleem aanpakken. De wijzigingen waren op 5 oktober klaar en kwamen uit met Mole 1.16.0; hieronder wat ik toen heb gemeten en welke afwegingen ik heb gemaakt.

Het lag niet aan de app zelf

Ik verwachtte dat grotere apps trager zouden zijn, en dat klopte niet: een klein hulpprogramma van 6,6 MB met zes restbestanden had bij de eerste klik nog steeds ongeveer 0,56 seconde nodig. De meeste tijd ging op aan een paar vaste klussen die bij elke klik draaiden. Dit zijn medianen van drie runs met een Release-build op mijn M5 Pro:

• Het inlezen van de cask-catalogus van Homebrew, een bestand van 5,6 MB, kostte elke keer zo'n 200 ms, alleen om te bepalen of de app met Homebrew was geïnstalleerd.
• De codehandtekening van de app werd gecontroleerd, en wel twee keer, met ongeveer 1 ms per MB uitvoerbaar bestand; MindNode was daar per klik 260 ms mee bezig.
• De traagste scantaak was de lijst met recente documenten: zo'n 230 ms voor 775 items, bijna allemaal besteed aan het een voor een controleren van paden.

Sommige apps legden er nog hun eigen kosten bovenop. Het installatiebewijs van Xcode is 41 MB groot en bevat 125.000 paden, en werd bij elke klik opnieuw ingelezen. ChatGPT laat ongeveer 15.000 tijdelijke mappen achter, en voor elke map moest apart worden nagegaan of die echt bij ChatGPT hoorde.

Wat er veranderd is

• De cask-catalogus wordt op de achtergrond gelezen zodra de verwijderpagina opengaat, niet pas bij de klik.
• De klik leest de handtekeninggegevens zonder ze te controleren en legt de app vast op zijn bestandsidentiteit. De volledige controle draait op de achtergrond nadat de lijst is verschenen, en moet klaar zijn voordat er iets wordt verwijderd.
• Recente documenten worden eerst op naam gefilterd; alleen wat overeenkomt, gaat door de volledige eigendomscontrole.
• De mappen in de bibliotheek worden parallel uitgelezen, de identiteit van containers wordt per metadatabestand in de cache bewaard, en de ID-voorvoegsels van hulpprogramma's worden één keer per scan berekend.
• Installatiebewijzen worden per bewijsbestand in de cache bewaard, zodat een tweede klik op Xcode die 41 MB niet opnieuw inleest.
• Tijdelijke mappen waarvan de naam al bewijst van wie ze zijn, nemen een snelle route; bij het verwijderen wordt nog steeds elk pad gecontroleerd.
• Lange scantaken starten als eerste, en de honderden kleine taken sluiten achter in de rij aan.
• Een scan die begint als je met de aanwijzer over een app gaat, stopt zodra de aanwijzer weg is, en een scan die vóór een verwijdering begon, kan daarna geen verouderde resultaten meer terugschrijven.

Bij de handtekeningcontrole was weglaten het makkelijkst geweest. Ik heb hem in plaats daarvan naar na de klik verplaatst. Als de controle op de achtergrond nu mislukt, wordt de app zelf toch verwijderd, en blijven alleen de soorten restbestanden staan die via de handtekeninggegevens zijn gevonden, zoals containers die op het team-ID van de ontwikkelaar zijn gekoppeld. In het resultaat staan ze als "Appsignatuur niet bevestigd", bewaard in plaats van mislukt. Een app die na de scan door een andere is vervangen, wordt nog steeds geweigerd.

Hoeveel sneller

Eerste klik ongeveer 1,5 seconde na het openen van de verwijderpagina, Release-build:

De meeste gangbare apps blijven nu onder de 250 ms, zodat de restbestanden in één keer verschijnen, zonder eerst "Scannen" te tonen. De handtekeningcontrole op de achtergrond is 12 tot 434 ms nadat de lijst verschijnt klaar.

De vijftienduizend regels van ChatGPT

Met snelle klikken haperde het scrollen door een uitgeklapte ChatGPT nog steeds. De lijst telde 15.175 regels, waarvan 15.143 tijdelijke mappen in de vorm T/.com.openai.codex.XXXXXX, samen 1,0 GB, en bij elke start van de app komen er een paar bij. Bij Hina, een app die ik zelf maak, was het vergelijkbaar: 323 van de 344 regels waren Hina-<Suite>-<UUID>.plist-bestanden van testruns, samen 0,01 MB. In beide gevallen vulde één willekeurig benoemde vorm bijna de hele lijst.

Het aantal regels was niet de enige oorzaak. De uitgeklapte regel sorteerde bij elke hertekening alle restbestanden opnieuw, en de aanwijzer erover bewegen hertekende de hele app-regel, zodat elke regel die onder een stilstaande aanwijzer door gleed opnieuw een sortering startte. Met de echte gegevens van ChatGPT ging één hertekening van 309 tot 354 ms naar 56 tot 58 ms, bij Hina van 33 tot 36 ms naar 17 tot 19 ms, en de uitgeklapte hoogte van ChatGPT kromp van 3200 pt naar 1225 pt.

Regels delen nu één regel als ze dezelfde categorie, map, eigenaar en standaardselectie hebben en hun namen alleen verschillen in een deel dat de app zelf heeft gemaakt: een willekeurig achtervoegsel, een UUID, een lange hexadecimale reeks of het tijdstempel van een crashrapport. De gedeelde regel houdt het categorielabel, toont het pad met * op de plek van het wisselende deel, gevolgd door het aantal items en de totale grootte, met één selectievakje, en klapt niet uit. ChatGPT ging zo terug naar 33 regels in 13 categorieën, Hina naar 24.

Mappen ernaast met een eigen naam houden elk hun eigen regel, zoals de zeven Electron-caches van ChatGPT, GPUCache, Code Cache, Crashpad en de rest. Als ik die ook had samengevoegd, hield Hina zo'n zeven regels over, en dat ziet er niet meer uit als grondig opruimen; een stuk of twaalf is ongeveer goed. Een naam met een woord van zes letters, zoals T/<id>.helper, krijgt ook een eigen regel, omdat zes letters alleen niet van een willekeurig achtervoegsel te onderscheiden zijn.

Twee eerdere pogingen bleven afgewezen. De ene stopte een inklapbare groep in de al uitgeklapte app-regel; uitgeprobeerd op 30 september en op 2 oktober weer weggehaald, omdat het uitklappen in uitklappen stopte en vergelijkbare paden over de groep en losse regels verdeelde. De andere toonde één regel per categorie; in gebruik vanaf 4 september en een week later teruggedraaid, omdat het verschillende locaties achter één regel verstopte.

Hoe andere verwijderprogramma's het doen

Pearcleaner leest ongeveer 62 mappen parallel uit en vergelijkt op naam, zonder eigendomsbewijs en zonder cache; het is snel omdat het minder doet. Tencent Lemon berekent de restbestanden van alle apps zodra je de pagina opent en vernieuwt ze dagelijks, dus klikken reageren meteen, ten koste van een grote achtergrondscan bij elk bezoek, wat ingaat tegen de regel van Mole om geen doorlopend werk toe te voegen. MangoDisk, Uninstally en Mole CLI gebruiken vaste mappen met beperkte parallelle verwerking.

Geen van allen had een snellere basisfunctie dan getattrlistbulk en readdir, die Mole al gebruikt. Ik heb ook Spotlight geprobeerd: elke zoekopdracht duurde 0,3 tot 0,4 seconde en miste de meeste restbestanden, want van de vier van VS Code vond hij er één, terwijl searchfs wel werkt op APFS maar zo'n 15 seconden per zoekopdracht nodig heeft. Uiteindelijk kwam het werk dus neer op dubbel werk weghalen uit de scan die Mole al had. Hoe je die lijst met restbestanden leest voordat je iets verwijdert, lees je in Restbestanden na verwijderen op de Mac: controleer ze voordat je ze wegdoet.