Pylance um Limit: Memory Leaks bei High-Frequency File Operations bändsegen

---

TL;DR (D'„Pylance-Diät")

Wann dir nëmmen eng Saach direkt ännere wëllt:

// settings.json
{
  "python.analysis.diagnosticMode": "openFilesOnly"
}

Dat eleng stoppt de stäerkste RAM-Verbrauch. De Rescht vun der Konfiguratioun follegt hei ënnen.

---

D'Problemfindung: Wann de Language Server zum Flaschenhals gëtt

Bei der Entwécklung vu ClutchPoint — enger VS Code Extension fir automatiséiert High-Frequency-File-Operatiounen — hunn ech festgestallt, datt VS Code bei héijer Dateifréquenz massiv ugefaangen huet ze ruckelen.

Mat menger Diagnos-Extension Gist Factor VS konnt ech den Täter séier isoléieren: ms-python.vscode-pylance.

De Problem: Pylance probéiert all nei erstellt oder geännert Fichier direkt ze indexéieren. Bei engem Workflow, deen honnerte temporär Fichieren erstellt, féiert dat zu:

• Massive Memory Leaks: de RAM-Verbrauch schéisst héich, ouni nees errofzekomm.
• Event-Loop Blocking: Pylance beläscht den Extension Host esou staark, datt aner Extensions — an d'UI selwer — mat Verzögerung reagéieren.
• Leaking Listeners: Iwwer 500 aktiv, net opgereegte Listener während schnelle Läschzyklen noweisbar.

---

D'Analyse: Firwat Pylance „läckt"

Pylance baséiert op Pyright. A Standardprojeten ass d'Verhalen — déift Indexéieren vun allen Workspace-Fichieren — gewiellt a sënnvoll. An enger High-Frequency-Ëmfeld oder bei grousse Workspaces (z.B. an enger Vagrant-Entwécklungsëmfeld) féiert dësen „Eifer" awer dozou, datt:

1. De Garbage Collector net méi mam Opraueme hannendrun kënnt.
2. All neit File-Event eng nei Analyse-Task triggert — an d'Queue kontinuéierlech wuesse gëtt.
3. Event-Listener fir Dateiännerungen ugemellt, awer net propper ofgemellt ginn.

D'Resultat ass en klasseschen Observer-Leak op Extension-Host-Niveau.

---

D'Léisung: D'„Pylance-Diät"

Fir d'Stabilitéit zréckzestellen, ouni op Pylance seng Intelligenz ze verzichten, hu mir eng dräi-Stufen-Strategie ëmgesat:

1) Konfiguratioun optiméieren (settings.json)

Den wichtegste Schrëtt ass, Pylance den „Eifer" ze huelen:

{
  "python.analysis.diagnosticMode": "openFilesOnly",
  "python.analysis.indexing": false,
  "python.analysis.packageIndexDepths": [
    { "name": "", "depth": 1 }
  ],
  "python.analysis.typeCheckingMode": "basic",
  "python.analysis.persistAllIndices": false
}

Wichteg: Dës Astellunge si bewosst restriktiv. Fir Teams mat groussen Python-Monorepos kënne si den Komfort liicht reduzéieren. Als Kompromëss empfehlt sech den Asaz a Workspace-Settings amplaz User-Settings — esou gëllt d'Diät nëmmen fir belaaschten Projeten.

2) Architektoneschen Upuass: Throttling a ClutchPoint

An der Extension-Logik vu ClutchPoint hu mir e Batching agefouert. Amplaz Pylance mat all eenzelem File-Event ze bombardéieren, ginn Operatiounen gruppéiert gebuedelt. Domat huet de Language Server Zäit fir ze „otmem":

// Vereinfacht — Batching amplaz all eenzel Save direkt ze triggeren
const pendingFiles = new Set<string>();
let batchTimer: NodeJS.Timeout | undefined;

function scheduleAnalysis(uri: vscode.Uri) {
  pendingFiles.add(uri.fsPath);
  if (batchTimer) clearTimeout(batchTimer);
  batchTimer = setTimeout(() => {
    // Pylance nëmmen eemol pro Batch informéieren
    pendingFiles.clear();
    batchTimer = undefined;
  }, 500); // 500ms Debounce
}

3) Transparenz fir den Notzer: Gist Factor VS

Duerch Gist Factor VS ginn mir dem Notzer elo Feedback: Wann d'Systemlatenz duerch Pylance eropgeet, erschéngt en Hinweis am Editor. Esou gëtt kloer, datt net déi eegen App, mee de Language Server gerade am Limit schafft — en „neutralen Schiedsrichter" tëscht Extension an Editor.

---

Bonus: Wat Gist Factor VS nach fonnt huet — LEAK_WEBVIEW_NO_DISPOSED_CHECK

Wärend der Analyse vun de Pylance-Leaks huet Gist Factor VS gläichzäiteg en zweete, wäitverbreet Fehlermuster a VS Code Extensions opgedeckt: LEAK_WEBVIEW_NO_DISPOSED_CHECK.

Hei e representativen Auszug aus dem echte Diagnose-Output (ofgekierzt; Original: 35 Treffer a 8 Fichieren):

[
  {
    "code": "LEAK_WEBVIEW_NO_DISPOSED_CHECK",
    "severity": 4,
    "message": "webview.postMessage called without a check for a disposed panel.",
    "source": "gistfactor",
    "startLineNumber": 209
  },
  {
    "code": "LEAK_WEBVIEW_NO_DISPOSED_CHECK",
    "severity": 4,
    "message": "webview.postMessage called without a check for a disposed panel.",
    "source": "gistfactor",
    "startLineNumber": 175
  }
]

Wat bedeit dat?

D'Muster ass einfach awer geféierlech: eng Extension schéckt Noriichten un e Webview-Panel — ouni ze prüfen, ob dat Panel nach op ass.

1. Notzer zoumaach e Dashboard-Tab → Panel gëtt disposed.
2. En asynchrone Prozess leeft nach a wëll e Resultat schécken.
3. webview.postMessage gëtt geruff → Fehler oder Zombie-Referenz am Speicher.

A engem Héichfrequenz-Szenario (ClutchPoint triggert dauerhaft File-Events, déi Dashboards wëllen aktualiséieren) summiert sech dat zu engem echte Leak-Problem.

De Fix: SafeMessenger

Amplaz iwwerall if (this.panel)-Prüfungen anzestreuen, léist e zentralen Wrapper d'Problem eemol fir ëmmer:

// src/runtime/safeMessenger.ts
import * as vscode from 'vscode';

export class SafeMessenger {
    private _isDisposed = false;

    constructor(private readonly _panel: vscode.WebviewPanel) {
        this._panel.onDidDispose(() => {
            this._isDisposed = true;
        });
    }

    public postMessage(message: unknown): void {
        if (this._isDisposed) {
            return; // Panel scho zou — Noriicht gëtt verworf
        }
        try {
            this._panel.webview.postMessage(message);
        } catch (err) {
            console.error('[SafeMessenger] Failed to send message:', err);
        }
    }

    public get isDisposed(): boolean {
        return this._isDisposed;
    }
}

Virdrun (risikoreich):

this.panel.webview.postMessage({ command: 'update', data: payload }); // ❌

Duerno (Gist Factor konform):

this.messenger.postMessage({ command: 'update', data: payload }); // ✅

Dëse Wrapper ass och d'Grondlag fir de Disturber Radar a Gist Factor VS: fehlgeschloen Sendeversuche kënnen geloggt a am Dashboard siichtbar gemaach ginn — esou gesäit een op ee Bléck, wéi eng Extensions aktiv probéieren, scho zou Panels unzespriichen.

---

Alternativen: Wann d'Diät net duergeet

Falls d'Konfiguratioun eleng net duergeet, ginn et zwou sënnvoll Alternativen:

Ruff (als Pylance-Entlaaschung)

Ruff ass en a Rust geschriwwent Linting- a Formatting-Tool — extrem séier a ressourceschounend. Et kann Pylance beim Linting komplett ersetzen a de Language Server op Type-Checking reduzéieren.

Viraussetzung: D'VS-Code-Extension charliermarsh.ruff muss installéiert sinn. Et ass recommandéiert, dësen Androck an d'VS-Code-User-Settings (%APPDATA%\Code\User\settings.json) anzetragen:

{
  "ruff.nativeServer": "on",
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff"
  }
}

Déi reng Zouweisung editor.defaultFormatter = charliermarsh.ruff gräift net, wann d'Extension feelt.

Ruff ersetzt Pylance net — Aufgabendeelung op ee Bléck:

Funktioun	Pylance	Ruff
IntelliSense / Autocomplete	✅	❌
Type-Checking (via Pyright)	✅	❌
Go-to-Definition	✅	❌
Hover-Docs / Signaturen	✅	❌
Linting (flake8, pylint…)	schwaach	✅
Formatting (Black-kompatibel)	❌	✅
Import-Sortéierung (isort)	❌	✅
Vitesse	normal	10–100× méi séier

Kann Ruff Pylance ersetzen? Nëmme partiell. Ruff iwwerhëlt Linting a Formatting komplett — awer kee IntelliSense, kee Type-Checking, kee Go-to-Definition. Wier dës IDE-Funktiounen brauch, brauch weiderhin Pylance.

Weiderliesen: Pylance oder Ruff? Wierkscher verstoen, richteg kombinéieren

Fir reng Script- a CLI-Projeten (Manifest-Prüfer, Automatiounswierkscher, Skripten déi primär am Terminal lafen): Pylance kann projektspezifësch komplett deaktivéiert ginn:

// .vscode/settings.json am Projektordner
{
  "python.languageServer": "None"
}

Ruff iwwerhëlt dann Linting a Formatting — den Extension Host bleift komplett entlaascht, ouni aner Projeten ze beaflossen.

BasedPyright (als Pylance-Ersatz)

BasedPyright ass e Community-Fork vum Pyright-Kär — ressourceneffizienter wéi Pylance an ouni Microsoft-Telemetrie. Fir Projeten, déi dauerhaft ënner Pylance leiden, eng ernstzuelend Optioun.

---

Fazit

Pylance ass mächteg — awer net fir jidder Ëmfeld ausgeluecht. Fir Entwéckler, déi mat automatiséierten Dateioperatiounen, grousse Vagrant-Workspaces oder Monorepos schaffen, ass eng „Diät" vun den Astellungen dacks onëmgänglech, fir den Extension Host stabil ze halen.

Den entscheede éischte Schrëtt:

"python.analysis.diagnosticMode": "openFilesOnly"

Beobacht duerno de RAM-Verbrauch vu pylance am Task Manager — den Ënnerscheed ass an der Regel direkt siichtbar.

Kontext: Testëmfeld

- OS: Windows 10 Home / Windows 11 - VS Code: 1.80+ - Pylance: ms-python.vscode-pylance - Vagrant-Workspace mat verschiddene oppene PHP/JS/Python-Projeten - Extension: ClutchPoint (High-Frequency File Operations) - Diagnos: Gist Factor VS

---