# Wie Moles Deinstallationsliste beim Klick sofort erscheint

> Wohin die Sekunde und mehr pro Klick beim Deinstallieren ging, was in den Hintergrund wanderte und warum ChatGPTs 15.000 temporäre Ordner jetzt eine Zeile teilen.

Published: 2026-10-28

Wer auf Moles Deinstallationsseite eine App anklickte, sah rechts erst kurz nichts, dann „Wird gescannt“, und erst nach einer halben bis ganzen Sekunde tauchten die Reste auf. Xcode brauchte bei jedem Klick drei bis vier Sekunden, ChatGPT sechs, und beim Scrollen durch die aufgeklappte ChatGPT-Liste ruckelte es. Ich wollte genau wissen, wo diese Zeit bleibt, und habe mir nebenbei angesehen, wie ein paar Open-Source-Deinstaller dasselbe Problem lösen. Die Änderungen waren am 5. Oktober fertig und kamen mit Mole 1.16.0 heraus; unten stehen die Messungen von damals und die Abwägungen, die ich getroffen habe.

## Langsam war nicht die App selbst

Ich hatte erwartet, dass größere Apps langsamer sind, das stimmte aber nicht: Ein kleines Tool mit 6,6 MB und sechs Resten brauchte beim ersten Klick trotzdem etwa 0,56 Sekunden. Die meiste Zeit ging für ein paar feste Arbeiten drauf, die bei jedem Klick liefen. Das sind Mediane aus drei Läufen mit einem Release-Build auf meinem M5 Pro:

- Homebrews Cask-Katalog, eine 5,6 MB große Datei, wurde jedes Mal in etwa 200 ms eingelesen, nur um festzustellen, ob die App über Homebrew installiert wurde.
- Die Codesignatur der App wurde geprüft, und zwar zweimal, mit ungefähr 1 ms pro MB ausführbarer Datei; bei MindNode waren das 260 ms pro Klick.
- Der langsamste Scan war die Liste der zuletzt benutzten Dokumente: etwa 230 ms für 775 Einträge, fast alles für die Prüfung der Pfade, einer nach dem anderen.

Manche Apps legten noch eigene Kosten obendrauf. Der Installationsbeleg von Xcode ist 41 MB groß und führt 125.000 Pfade, und er wurde bei jedem Klick neu gelesen. ChatGPT hinterlässt rund 15.000 temporäre Ordner, und für jeden musste einzeln geprüft werden, ob er wirklich dazugehört.

## Was sich geändert hat

- Der Cask-Katalog wird im Hintergrund gelesen, sobald die Deinstallationsseite aufgeht, nicht erst beim Klick.
- Der Klick liest die Signaturinformationen, ohne sie zu prüfen, und hält die App über ihre Dateiidentität fest. Die vollständige Prüfung läuft im Hintergrund, nachdem die Liste erschienen ist, und muss abgeschlossen sein, bevor etwas gelöscht wird.
- Zuletzt benutzte Dokumente werden zuerst nach Namen gefiltert; nur passende Einträge durchlaufen die vollständige Eigentumsprüfung.
- Die Library-Wurzeln werden parallel aufgelistet, Container-Identitäten pro Metadatendatei zwischengespeichert, und die Präfixe der Hilfsprogramm-IDs werden einmal pro Scan berechnet.
- Installationsbelege werden pro Belegdatei zwischengespeichert, sodass ein zweiter Klick auf Xcode diese 41 MB nicht noch einmal liest.
- Temporäre Ordner, deren Name allein schon beweist, wem sie gehören, nehmen einen schnellen Weg; beim Löschen wird trotzdem jeder Pfad geprüft.
- Lange Scans starten zuerst, die Hunderte kleiner Aufgaben reihen sich dahinter ein.
- Ein Scan, der beim Darüberfahren mit der Maus beginnt, stoppt, sobald der Zeiger weg ist, und ein Scan, der vor einer Deinstallation begonnen hat, kann danach keine veralteten Ergebnisse mehr zurückschreiben.

Bei der Signaturprüfung wäre es am einfachsten gewesen, sie wegzulassen. Ich habe sie stattdessen hinter den Klick verschoben. Scheitert die Prüfung im Hintergrund, wird die App selbst trotzdem deinstalliert, und nur die Arten von Resten, die über die Signaturinformationen gefunden wurden, bleiben liegen, etwa Container, die über die Team-ID des Entwicklers zugeordnet wurden. Im Ergebnis stehen sie als „App-Signatur nicht bestätigt“, behalten statt fehlgeschlagen. Eine App, die nach dem Scan durch eine andere ersetzt wurde, wird weiterhin abgelehnt.

## Wie viel schneller

Erster Klick etwa 1,5 Sekunden nach dem Öffnen der Deinstallationsseite, Release-Build:

| App | Vorher | Nachher |
| --- | --- | --- |
| Shottr | 556 ms | 137 ms |
| MindNode | 1233 ms | 169 ms |
| Raycast | 716 ms | 171 ms |
| Parallels Desktop | 871 ms | 194 ms |
| VS Code | 584 ms | 232 ms |
| WeChat | 605 ms | 238 ms |
| Xcode | 3689 ms | 384 ms |
| ChatGPT | 6134 ms | 1530 ms |

Die meisten gängigen Apps landen jetzt unter 250 ms, sodass die Reste in einem Schritt erscheinen, ohne vorher „Wird gescannt“ zu zeigen. Die Signaturprüfung im Hintergrund ist 12 bis 434 ms nach dem Erscheinen der Liste fertig.

## ChatGPTs fünfzehntausend Zeilen

Mit schnellen Klicks ruckelte das Scrollen durch ein aufgeklapptes ChatGPT immer noch. Es listete 15.175 Zeilen, und 15.143 davon waren temporäre Ordner der Form `T/.com.openai.codex.XXXXXX`, zusammen 1,0 GB, bei jedem Start der App kommen ein paar dazu. Bei Hina, einer App von mir, sah es ähnlich aus: 323 der 344 Zeilen waren `Hina-<Suite>-<UUID>.plist`-Dateien aus Testläufen, zusammen 0,01 MB. In beiden Fällen füllte eine einzige zufällig benannte Form fast die ganze Liste.

Die Zeilenzahl war nicht die einzige Ursache. Die aufgeklappte Zeile sortierte bei jedem Neuzeichnen alle Reste neu, und das Darüberfahren zeichnete die ganze App-Zeile neu, sodass jede Zeile, die unter einem ruhenden Zeiger vorbeiglitt, eine weitere Sortierung auslöste. Mit den echten ChatGPT-Daten sank ein Neuzeichnen von 309 bis 354 ms auf 56 bis 58 ms, bei Hina von 33 bis 36 ms auf 17 bis 19 ms, und die aufgeklappte Höhe von ChatGPT schrumpfte von 3200 pt auf 1225 pt.

Zeilen teilen sich jetzt eine Zeile, wenn Kategorie, Ordner, Eigentümer und Standardauswahl übereinstimmen und sich ihre Namen nur in einem Teil unterscheiden, den die App selbst erzeugt hat: einem zufälligen Suffix, einer UUID, einer langen Hex-Folge oder einem Zeitstempel aus einem Absturzbericht. Die gemeinsame Zeile behält die Kategoriebezeichnung, zeigt den Pfad mit `*` an der veränderlichen Stelle, dahinter Anzahl und Gesamtgröße, mit einem einzigen Häkchen, und lässt sich nicht aufklappen. ChatGPT kam so auf 33 Zeilen in 13 Kategorien, Hina auf 24.

<figure class="blog-diagram">
  <picture>
    <source media="(max-width: 900px)" srcset="/img/blog/uninstall-leftovers-one-line-mobile.webp">
    <img src="https://mole.fit/img/blog/uninstall-leftovers-one-line.webp" width="1600" height="992" loading="lazy" alt="Dieselben ChatGPT-Reste vorher und nachher: vorher hat jeder temporäre Ordner eine eigene Zeile, nachher teilen sie sich eine Zeile mit 15.143 Objekten und 1,02 GB, die übrigen Reste stehen nach Kategorie geordnet.">
  </picture>
  <figcaption>Dieselben ChatGPT-Reste, vorher eine Zeile pro temporärem Ordner, nachher eine gemeinsame Zeile.</figcaption>
</figure>

Geschwister mit eigenen Namen behalten ihre eigenen Zeilen, etwa die sieben Electron-Caches von ChatGPT, `GPUCache`, `Code Cache`, `Crashpad` und die übrigen. Hätte ich auch die zusammengefasst, wären bei Hina etwa sieben Zeilen übrig geblieben, und das sieht nicht mehr nach gründlichem Aufräumen aus; ein gutes Dutzend ist ungefähr richtig. Ein Name mit einem Wort aus sechs Buchstaben, etwa `T/<id>.helper`, bleibt ebenfalls in einer eigenen Zeile, weil sich sechs Buchstaben allein nicht von einem zufälligen Suffix unterscheiden lassen.

Zwei frühere Versuche blieben verworfen. Der eine schachtelte eine aufklappbare Gruppe in die bereits aufgeklappte App-Zeile; ausprobiert am 30. September, entfernt am 2. Oktober, weil er Aufklappen ins Aufklappen packte und ähnliche Pfade zwischen Gruppe und losen Zeilen aufteilte. Der andere zeigte eine Zeile pro Kategorie; im Einsatz ab dem 4. September und eine Woche später zurückgenommen, weil er getrennte Orte hinter einer Zeile versteckte.

## Wie andere Deinstaller das machen

Pearcleaner listet etwa 62 Wurzeln parallel auf und gleicht nach Namen ab, ohne Eigentumsnachweis und ohne Cache; schnell ist es, weil es weniger tut. Tencent Lemon berechnet die Reste aller Apps, sobald man die Seite öffnet, und aktualisiert sie täglich, also reagieren Klicks sofort, um den Preis eines großen Hintergrundscans bei jedem Besuch, was Moles Regel widerspricht, keine dauerhafte Hintergrundarbeit hinzuzufügen. MangoDisk, Uninstally und die Mole CLI nutzen feste Wurzeln mit begrenzter Parallelität.

Keines davon hatte eine schnellere Grundlage als `getattrlistbulk` und `readdir`, die Mole bereits nutzt. Auch Spotlight habe ich ausprobiert: Jede Abfrage dauerte 0,3 bis 0,4 Sekunden und übersah die meisten Reste, von den vier bei VS Code fand sie einen, während `searchfs` auf APFS zwar funktioniert, aber etwa 15 Sekunden pro Abfrage braucht. Am Ende ging es also darum, doppelte Arbeit aus dem Scan zu entfernen, den Mole schon hatte. Wie man diese Liste der Reste vor dem Löschen liest, steht in [App-Reste auf dem Mac: Vor dem Löschen genau prüfen](https://mole.fit/de/blog/mac-uninstall-leftovers-review-before-delete).

---

Canonical HTML page: https://mole.fit/de/blog/mole-uninstall-review-speed
Blog index for agents: https://mole.fit/de/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
