Performance-Probleme in PhpStorm selbst beheben: Index, Plugins, Heap, Excludes

1. Zuerst diagnostizieren, dann optimieren

Performance-Optimierung ohne Diagnose ist Raten. PhpStorm zeigt in der Statusleiste unten rechts den aktuellen Heap-Verbrauch an – wenn er dauerhaft über 80% liegt und PhpStorm häufig den Garbage Collector auslöst (erkennbar am kurzzeitigen Einfrieren), ist Heap-Mangel die wahrscheinlichste Ursache. Das Statusleisten-Widget für den Heap aktiviert man über Help → Edit Custom VM Options oder indem man in der Statusleiste mit der rechten Maustaste klickt und Memory Indicator aktiviert.

Der zweite Diagnoseschritt ist der Blick auf die Indexierungsaktivität. Während PhpStorm indexiert, sind viele Funktionen – Autovervollständigung, Navigation, Inspektionen – verlangsamt oder nicht verfügbar. Die Fortschrittsanzeige unten in der IDE zeigt aktive Hintergrundprozesse. Wenn PhpStorm nach dem Öffnen eines Magento-Projekts 10–15 Minuten mit der Indexierung beschäftigt ist, deutet das auf zu viele eingeschlossene Dateien hin – typischerweise der gesamte vendor-Ordner mit allen Dev-Dependencies, Testdateien und generierten Assets.

2. Heap-Größe korrekt einstellen

PhpStorm läuft auf der JVM und hat standardmäßig einen maximalen Heap von 2 GB. Für ein Magento-2-Projekt mit typischerweise 200.000+ PHP-Dateien im Vendor-Verzeichnis reicht das kaum. Die praktische Empfehlung: 4–6 GB Heap bei Systemen mit 16+ GB RAM, 3–4 GB bei 8 GB RAM. Die Einstellung erfolgt über Help → Change Memory Settings (der komfortable Weg) oder über Help → Edit Custom VM Options für erweiterte Einstellungen.

Zu viel Heap ist ebenfalls schädlich: Ein sehr großer Heap verlängert Garbage-Collection-Pausen, weil der GC mehr Speicher durchsuchen muss. Die optimale Heap-Größe liegt meist bei 60–70% des verfügbaren physischen RAMs, sofern keine anderen speicherintensiven Programme gleichzeitig laufen. Mit aktiviertem Memory-Indicator in der Statusleiste kann man nach dem Neustart beobachten, ob der Heap-Verbrauch jetzt komfortabel unter 70% bleibt oder nach wie vor ans Maximum stößt.

# PhpStorm VM Options — Help → Edit Custom VM Options
# Datei: ~/.config/JetBrains/PhpStorm2025.1/phpstorm.vmoptions (Linux)
#        ~/Library/Application Support/JetBrains/PhpStorm2025.1/phpstorm.vmoptions (macOS)

# Heap-Größe (für 16 GB RAM-System empfohlen)
-Xms1g
-Xmx6g

# Direkten Speicher erhöhen (für große Indexe nötig)
-XX:MaxDirectMemorySize=2g

# Garbage Collector: G1GC ist Standard in neueren JVMs — nicht ändern
# -XX:+UseG1GC  ← bereits Standard

# GC-Pausen begrenzen (in Millisekunden)
-XX:MaxGCPauseMillis=200

# Soft-Referenzen weniger aggressiv freigeben (verbessert Code-Completion-Cache)
-XX:SoftRefLRUPolicyMSPerMB=50

# File Watcher Buffer (Linux) — erhöhen wenn "inotify watches" Fehler auftreten
# In /proc/sys/fs/inotify/max_user_watches: echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches

3. Index-Excludes: Was PhpStorm nicht wissen muss

Der wirkungsvollste einzelne Schritt zur Performance-Verbesserung bei Magento-Projekten ist das korrekte Konfigurieren von Exclude-Verzeichnissen. PhpStorm muss den kompletten vendor-Ordner kennen, um Autovervollständigung und Navigation anzubieten – aber er muss nicht pub/static, var, generated und dev/tests indexieren. Diese Verzeichnisse enthalten entweder generierte Dateien, kompilierte Assets oder Testinfrastruktur, die für die tägliche Entwicklungsarbeit nicht relevant ist.

Verzeichnisse als Excluded markiert man per Rechtsklick auf den Ordner in der Projektstruktur → Mark Directory As → Excluded. Alternativ in den Projekteinstellungen unter Settings → Directories. Ausgeschlossene Verzeichnisse werden orange dargestellt und nicht indexiert. Der Effekt ist unmittelbar: Die nächste Indexierung ist deutlich kürzer. In Magento-Projekten sollte man mindestens pub/static, pub/media, var, generated und dev/tests/performance ausschließen.

4. Plugin-Audit: Weniger ist mehr

Jedes aktive Plugin in PhpStorm verbraucht Ressourcen – auch wenn man es gerade nicht nutzt. Viele Entwickler akkumulieren über Monate Dutzende von Plugins, von denen sie die Hälfte nicht mehr aktiv verwenden. Das Plugin-Audit unter Settings → Plugins sollte mindestens einmal pro Quartal stattfinden. Für ein PHP-Magento-Projekt braucht man kein Django-Plugin, kein Rust-Plugin und kein Kubernetes-Helm-Chart-Plugin.

Besonders ressourcenintensive Plugin-Kategorien sind: Plugins mit eigenen Hintergrundindexen (z.B. zusätzliche Sprachunterstützungen), Plugins die Git-Operationen beobachten (außer dem eingebauten Git-Plugin), und Plugins die eigene Inspektionen zu jedem Tastendruck hinzufügen. Der Test: Alle Nicht-PHP-Plugins deaktivieren, PhpStorm neu starten und die Reaktionszeit messen. Oft ist der Unterschied zwischen 30 aktiven und 15 aktiven Plugins deutlich spürbar.

# Empfohlene Plugins für Magento 2 / PHP Entwicklung (aktiv halten)
# ─── Essentiell ───────────────────────────────────────────────────
# PHP                    ← PHP-Unterstützung (eingebaut, nicht deaktivierbar)
# Symfony                ← DI-Container, YAML, Twig
# Magento PhpStorm       ← Magento-spezifische Unterstützung (falls vorhanden)
# GitToolBox             ← Nützlich, aber performance-relevant
# .env files support     ← Für docker-compose und PHP dotenv
# Docker                 ← Docker-Integration für PhpStorm
# Database Tools         ← SQL + MySQL-Verbindung

# ─── Situativ aktivieren ──────────────────────────────────────────
# Tailwind CSS           ← Nur aktiv wenn aktiv an CSS gearbeitet wird
# Prettier               ← Nur wenn Prettier im Projekt verwendet wird

# ─── Deaktivieren für reine PHP-Arbeit ───────────────────────────
# Go                     ← Nicht benötigt
# Rust                   ← Nicht benötigt
# Kubernetes             ← Nicht benötigt für Magento-Entwicklung
# Terraform              ← Nicht benötigt
# Angular                ← Nicht benötigt (kein AngularJS in Hyvä)

5. Power Save Mode und Inspektionen selektiv deaktivieren

Der Power Save Mode in PhpStorm (File → Power Save Mode) deaktiviert alle Hintergrundanalysen temporär: keine Inspektionen beim Tippen, keine automatische Indexierung, keine Code-Completion-Updates im Hintergrund. Das ist das schärfste Mittel, wenn man schnell einen langen Refactoring-Vorgang durchführen oder eine große Datei lesen möchte, ohne dass die IDE ständig im Hintergrund Ressourcen verbraucht. Nach dem Ende der Arbeit den Power Save Mode wieder deaktivieren.

Eine feinere Alternative ist die selektive Deaktivierung von Inspektionen. PhpStorm enthält hunderte von Inspektionsregeln, viele davon für Sprachen oder Frameworks, die man im konkreten Projekt nicht nutzt. Unter Settings → Editor → Inspections kann man ganze Kategorien deaktivieren. Für ein reines PHP-Projekt braucht man keine JavaScript-Inspektionen auf Niveau "Error" – "Warning" reicht, wenn man sich auf PHP konzentriert. Das Profil kann exportiert und im Team geteilt werden, damit alle Entwickler dieselbe Inspektion-Konfiguration nutzen.

6. JVM-Optionen für PHP-Projekte tunen

Neben der Heap-Größe gibt es weitere JVM-Optionen, die PhpStorm bei großen PHP-Projekten spürbar beschleunigen. Die Option -XX:SoftRefLRUPolicyMSPerMB=50 verlängert die Lebensdauer von Code-Completion-Caches, wodurch die IDE bei häufig genutzten Klassen weniger neu laden muss. Die Option -XX:MaxDirectMemorySize=2g erhöht den Direktspeicher, der für große Indexe benötigt wird und bei Magento-Projekten mit tausenden Klassen schnell erschöpft ist.

Auf Linux-Systemen ist außerdem die Anzahl der inotify-Watches entscheidend. PhpStorm nutzt den File-Watcher des Betriebssystems, um Dateiänderungen zu erkennen. Bei Magento-Projekten mit 200.000+ Dateien kann das Standardlimit von 8.192 Watches erschöpft sein, was PhpStorm zu langsamem Polling zwingt. Das Limit dauerhaft erhöhen: echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p. Der Effekt: schnellere Erkennung von Dateiänderungen und weniger CPU-Last durch Polling.

7. Eingebauten Profiler nutzen

PhpStorm enthält seit Version 2022.1 einen eingebauten IDE-Profiler, der analysiert, welche IDE-Komponenten die meisten Ressourcen verbrauchen. Der Profiler wird über Help → Diagnostic Tools → Record IDE Internal Performance Snapshot gestartet. Nach 30–60 Sekunden normaler Arbeit stoppt man die Aufnahme und öffnet den Snapshot. Die Flame-Graph-Ansicht zeigt sofort, ob ein bestimmtes Plugin, eine Inspektion oder ein Hintergrundprozess unverhältnismäßig viele CPU-Zyklen beansprucht.

Typische Befunde in Magento-Projekten: Das PHP-Indexierungsmodul braucht beim Öffnen des Projekts mehrere Minuten, weil es vendor/magento mit 70.000+ PHP-Dateien vollständig analysiert. Ein bestimmtes Plugin wie der Symfony-Plugin-Inspector hat einen Regex-Fehler und läuft bei jedem Tastendruck 200ms. Ein externes Filesystem-Watching-Tool konkurriert mit PhpStorm um File-System-Events. Der Profiler macht solche Probleme sichtbar und damit lösbar – ohne den Profiler bleibt Performance-Optimierung Rätselraten.

# Verzeichnisse für Magento 2 als "Excluded" markieren
# Rechtsklick auf Ordner → Mark Directory As → Excluded

# Zwingend ausschließen (kein PHP-Code der navigierbar sein muss):
#   src/pub/static/           ← Kompilierte CSS/JS-Assets
#   src/pub/media/            ← Hochgeladene Bilder und Dateien
#   src/var/                  ← Cache, Logs, Sessions, Reports
#   src/generated/            ← Magento-generierte Proxies und Factories
#   src/dev/tests/performance ← Performance-Fixtures (sehr viele Dateien)

# Optional ausschließen (verringert Index, vermindert Navigation):
#   src/vendor/magento/magento2-functional-testing-framework
#   src/vendor/phpunit/
#   src/vendor/squizlabs/
#   src/vendor/friendsofphp/

# Als "Library Root" markieren (indexiert, aber nicht als Projektdateien):
#   src/vendor/               ← Navigation bleibt erhalten, weniger Inspektionen
# Rechtsklick → Mark Directory As → Library Root

# Prüfen wie viele Dateien indexiert werden:
# Help → Diagnostic Tools → Analyze IDE Startup Performance

8. Konkrete Optimierungen für Magento-2-Projekte

Magento 2 ist eines der größten PHP-Projekte, die PhpStorm indexieren muss. Ein typisches Magento-2-Projekt mit allen Abhängigkeiten enthält über 300.000 Dateien im vendor-Verzeichnis. Die effektivste Einzelmaßnahme ist es, vendor als Library Root zu markieren statt als normalen Projektordner. Library-Roots werden indexiert (Navigation und Autovervollständigung funktionieren), aber PhpStorm führt keine Projekt-Inspektionen auf ihnen aus, was die kontinuierliche Hintergrundanalyse drastisch reduziert.

Eine weitere Magento-spezifische Optimierung: Den PHP-Scope für Inspektionen auf app/code und das Theme-Verzeichnis beschränken. Unter Settings → Editor → Inspections kann man für jede Inspektion einen Scope konfigurieren. Wer nur eigenen Code inspizieren möchte, erstellt einen Scope "Projekt ohne Vendor" und wendet alle teuren Inspektionen (PHP-Kompatibilität, PHPDoc-Vollständigkeit, ungenutzte Importe) nur auf diesen Scope an. Das reduziert die Analysemenge von 300.000 auf typischerweise 2.000–5.000 eigene PHP-Dateien.

9. Maßnahmen im Wirkungsvergleich

Nicht alle Performance-Maßnahmen sind gleich wirkungsvoll. Die folgende Tabelle ordnet die beschriebenen Optimierungen nach ihrer typischen Wirkung und dem Aufwand für die Implementierung.

Die wichtigste Erkenntnis aus dem Vergleich: Index-Excludes und Heap-Größe haben den größten Effekt beim geringsten Aufwand. Wer nur eine Maßnahme umsetzen kann, sollte mit diesen beiden beginnen. Das Deaktivieren von Plugins hat einen spürbaren, aber selteneren direkten Effekt – es lohnt sich vor allem dann, wenn der Profiler ein bestimmtes Plugin als Verursacher identifiziert hat.

10. Zusammenfassung

PhpStorm-Performance-Probleme bei großen PHP-Projekten haben in fast allen Fällen dieselben Ursachen: zu viele Dateien im Index, zu wenig Heap-Speicher und zu viele aktive Plugins. Die Reihenfolge der Maßnahmen ist wichtig: Erst Index-Excludes konfigurieren (pub/static, var, generated), dann Heap-Größe anpassen, dann Plugins auditieren. Erst danach lohnen sich feinere Optimierungen wie JVM-Tuning, selektive Inspektion-Konfiguration und Library-Root-Markierungen.

Der eingebaute Profiler macht Performance-Probleme sichtbar und ersetzt Vermutungen durch Fakten. Wenn ein bestimmtes Plugin oder eine Inspektion 80% der CPU-Zeit verbraucht, ist die Lösung klar: dieses Plugin deaktivieren oder diese Inspektion einschränken. Ohne den Profiler könnte man Stunden damit verbringen, die falschen Optionen zu tunen. Mit ihm findet man die Ursache in wenigen Minuten.

11. FAQ: PhpStorm Performance-Probleme