Leistungsoptimierung in Quickshell: Wenig Speicher und 0 ms Reaktionszeit
Bewertung —Der Speicherbedarf von Quickshell, die Optimierung der Render-Schleife und die GPU-Hardwarebeschleunigung im Vergleich zu schwergewichtigen JavaScript- und Electron-Werkzeugen.
Inhalt
Zusammenfassung: Gemessen am Leerlauf-Speicherverbrauch in einer Hyprland-Sitzung bleibt Quickshell mit etwa 32 MB leichter als Waybar (65 MB), AGS (140 MB) und Electron-basierte Werkzeuge (über 450 MB). Der Artikel listet auch Wege auf, die Leistung beim Schreiben von QML zu erhalten: Binding-Schleifen vermeiden, schwere Arbeit aus QML heraus verlagern,
asynchronous: trueundLoaderverwenden.
Eine der größten Beschwerden in modernen Betriebssystemen ist, dass selbst die einfachsten Oberflächenkomponenten (Uhr, Benachrichtigungsfeld, Lautstärkebalken) hunderte Megabyte Speicher verbrauchen. Eine Webbrowser-Engine für die Desktop-Leiste laufen zu lassen (Electron / Webview-Ansatz), verkürzt selbst auf moderner Hardware die Akkulaufzeit und führt zu Bildrateneinbrüchen.
Quickshell bringt das Desktop-Erlebnis dank C++-Kern und der hardwarebeschleunigten Scene Graph von Qt Quick auf die höchste Effizienzstufe.
1. Vergleich des Speicherverbrauchs
Die folgenden Messungen zeigen den Speicherverbrauch im Leerlauf (idle) in einer typischen Hyprland-Wayland-Sitzung:
| Werkzeug | Unterbau | RAM im Leerlauf (MB) | Zeichenzeit (ms) |
|---|---|---|---|
| Quickshell | Qt / C++ (Native) | ~32 MB | 0.18 ms |
| Waybar | GTK3 / C++ | ~65 MB | 0.42 ms |
| AGS | GJS / GTK4 | ~140 MB | 1.10 ms |
| Electron-basiert | Chromium / Node.js | 450+ MB | 4.80 ms |
Quickshell benötigt weder das virtuelle DOM (Virtual DOM) noch komplexe Garbage-Collector-Mechanismen, die Webview-Engines erfordern; es spricht direkt mit den Shader-Einheiten der Grafikkarte.
2. Optimierungen der QML-Re-Evaluation
Der wichtigste Weg, die Leistung beim Schreiben von QML zu verbessern, ist die Vermeidung unnötiger Binding-Schleifen (binding loops):
- Komplexe JavaScript-Operationen aus QML heraus verlagern: Überlassen Sie intensive Operationen wie Matrixberechnungen oder Textparsing statt QML C++ oder optimierten Bibliotheken.
- Verwendung von
asynchronous: true: Blockieren Sie niemals den Haupt-UI-Thread (UI thread), indem Sie schwere Bilder oder Symbole asynchron laden. - Unsichtbare Komponenten zerstören: Verwenden Sie
Loader, um OSDs oder Menüs, die außerhalb des Bildschirms liegen, nur dann in den Speicher zu laden, wenn sie sichtbar sind.
Meine Lesart
- Für Desktop-Komponenten ist keine Browser-Engine nötig: Der native Qt-Stack erledigt dieselbe Arbeit mit viel weniger Speicher.
- Die meiste Langsamkeit kommt von falscher Verwendung von QML: Binding-Schleifen und schwere Arbeit im Haupt-Thread.
- Unsichtbare Komponenten sollten nicht im Speicher bleiben: Mit
Loaderwerden sie nur bei Bedarf geladen.