Fixing PhpStorm Performance Problems Yourself: Index, Plugins, Heap, Excludes

1. Diagnose first, optimize second

Performance optimization without diagnosis is guesswork. PhpStorm shows the current heap consumption in the status bar at the bottom right, if it stays permanently above 80% and PhpStorm frequently triggers the garbage collector (noticeable as brief freezes), lack of heap is the most likely cause. The status bar widget for the heap is enabled via Help → Edit Custom VM Options or by right clicking the status bar and enabling Memory Indicator.

The second diagnostic step is watching the indexing activity. While PhpStorm is indexing, many features (autocompletion, navigation, inspections) are slowed down or unavailable. The progress indicator at the bottom of the IDE shows active background processes. If PhpStorm spends 10 to 15 minutes indexing after opening a Magento project, that points to too many included files, typically the entire vendor folder with all dev dependencies, test files and generated assets.

2. Setting the heap size correctly

PhpStorm runs on the JVM and has a default maximum heap of 2 GB. For a Magento 2 project with typically 200,000+ PHP files in the vendor directory, that is barely enough. The practical recommendation: 4 to 6 GB heap on systems with 16+ GB RAM, 3 to 4 GB on 8 GB RAM. This is set via Help → Change Memory Settings (the convenient way) or via Help → Edit Custom VM Options for advanced settings.

Too much heap is also harmful: a very large heap lengthens garbage collection pauses because the GC has to search through more memory. The optimal heap size is usually 60 to 70% of the available physical RAM, provided no other memory intensive programs are running at the same time. With the memory indicator enabled in the status bar, you can observe after a restart whether heap consumption now comfortably stays below 70% or still hits the maximum.

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

# Heap size (recommended for a 16 GB RAM system)
-Xms1g
-Xmx6g

# Increase direct memory (needed for large indexes)
-XX:MaxDirectMemorySize=2g

# Garbage collector: G1GC is the default in newer JVMs, do not change
# -XX:+UseG1GC  ← already the default

# Limit GC pauses (in milliseconds)
-XX:MaxGCPauseMillis=200

# Release soft references less aggressively (improves the code completion cache)
-XX:SoftRefLRUPolicyMSPerMB=50

# File watcher buffer (Linux), increase if "inotify watches" errors occur
# In /proc/sys/fs/inotify/max_user_watches: echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches

3. Index excludes: what PhpStorm does not need to know

The single most effective step for improving performance on Magento projects is correctly configuring exclude directories. PhpStorm needs to know the entire vendor folder to offer autocompletion and navigation, but it does not need to index pub/static, var, generated and dev/tests. These directories contain either generated files, compiled assets or test infrastructure that is not relevant for daily development work.

Directories are marked as Excluded by right clicking the folder in the project structure and choosing Mark Directory As → Excluded. Alternatively, this can be done in the project settings under Settings → Directories. Excluded directories are shown in orange and are not indexed. The effect is immediate: the next indexing run is noticeably shorter. On Magento projects, at minimum pub/static, pub/media, var, generated and dev/tests/performance should be excluded.

4. Plugin audit: less is more

Every active plugin in PhpStorm consumes resources, even when you are not currently using it. Many developers accumulate dozens of plugins over months, half of which they no longer actively use. The plugin audit under Settings → Plugins should happen at least once per quarter. For a PHP Magento project, you do not need a Django plugin, a Rust plugin or a Kubernetes Helm chart plugin.

Particularly resource intensive plugin categories are: plugins with their own background indexes (for example additional language support), plugins that watch Git operations (other than the built in Git plugin), and plugins that add their own inspections on every keystroke. The test: disable all non PHP plugins, restart PhpStorm and measure the response time. Often the difference between 30 active and 15 active plugins is clearly noticeable.

# Recommended plugins for Magento 2 / PHP development (keep active)
# ─── Essential ────────────────────────────────────────────────────
# PHP                    ← PHP support (built in, cannot be disabled)
# Symfony                ← DI container, YAML, Twig
# Magento PhpStorm       ← Magento specific support (if available)
# GitToolBox             ← Useful, but performance relevant
# .env files support     ← For docker-compose and PHP dotenv
# Docker                 ← Docker integration for PhpStorm
# Database Tools         ← SQL + MySQL connection

# ─── Enable situationally ─────────────────────────────────────────
# Tailwind CSS           ← Only active while actively working on CSS
# Prettier               ← Only if Prettier is used in the project

# ─── Disable for pure PHP work ────────────────────────────────────
# Go                     ← Not needed
# Rust                   ← Not needed
# Kubernetes             ← Not needed for Magento development
# Terraform              ← Not needed
# Angular                ← Not needed (no AngularJS in Hyvä)

5. Power Save Mode and selectively disabling inspections

Power Save Mode in PhpStorm (File → Power Save Mode) temporarily disables all background analysis: no inspections while typing, no automatic indexing, no code completion updates in the background. This is the sharpest tool when you want to quickly run through a long refactoring pass or read a large file without the IDE constantly consuming resources in the background. Remember to disable Power Save Mode again once the work is done.

A finer grained alternative is selectively disabling inspections. PhpStorm contains hundreds of inspection rules, many of them for languages or frameworks that are not used in the specific project. Under Settings → Editor → Inspections entire categories can be disabled. For a pure PHP project you do not need JavaScript inspections at "Error" level, "Warning" is enough if you are focused on PHP. The profile can be exported and shared across the team so all developers use the same inspection configuration.

6. Tuning JVM options for PHP projects

Besides the heap size, there are other JVM options that noticeably speed up PhpStorm on large PHP projects. The option -XX:SoftRefLRUPolicyMSPerMB=50 extends the lifetime of code completion caches, so the IDE has to reload less for frequently used classes. The option -XX:MaxDirectMemorySize=2g increases the direct memory needed for large indexes, which is quickly exhausted on Magento projects with thousands of classes.

On Linux systems, the number of inotify watches is also decisive. PhpStorm uses the operating system's file watcher to detect file changes. On Magento projects with 200,000+ files, the default limit of 8,192 watches can be exhausted, forcing PhpStorm into slow polling. Increase the limit permanently: echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p. The effect: faster detection of file changes and less CPU load from polling.

7. Using the built in profiler

Since version 2022.1, PhpStorm has included a built in IDE profiler that analyzes which IDE components consume the most resources. The profiler is started via Help → Diagnostic Tools → Record IDE Internal Performance Snapshot. After 30 to 60 seconds of normal work, stop the recording and open the snapshot. The flame graph view immediately shows whether a particular plugin, an inspection or a background process is claiming a disproportionate amount of CPU cycles.

Typical findings on Magento projects: the PHP indexing module needs several minutes when opening the project because it fully analyzes vendor/magento with 70,000+ PHP files. A particular plugin such as the Symfony plugin inspector has a regex bug and runs for 200ms on every keystroke. An external filesystem watching tool competes with PhpStorm for file system events. The profiler makes such problems visible and therefore solvable, without the profiler, performance optimization remains guesswork.

# Mark directories for Magento 2 as "Excluded"
# Right click folder → Mark Directory As → Excluded

# Must exclude (no PHP code that needs to be navigable):
#   src/pub/static/           ← Compiled CSS/JS assets
#   src/pub/media/            ← Uploaded images and files
#   src/var/                  ← Cache, logs, sessions, reports
#   src/generated/             ← Magento generated proxies and factories
#   src/dev/tests/performance ← Performance fixtures (very many files)

# Optional exclude (reduces the index, limits navigation):
#   src/vendor/magento/magento2-functional-testing-framework
#   src/vendor/phpunit/
#   src/vendor/squizlabs/
#   src/vendor/friendsofphp/

# Mark as "Library Root" (indexed, but not as project files):
#   src/vendor/               ← Navigation stays intact, fewer inspections
# Right click → Mark Directory As → Library Root

# Check how many files are indexed:
# Help → Diagnostic Tools → Analyze IDE Startup Performance

8. Concrete optimizations for Magento 2 projects

Magento 2 is one of the largest PHP projects PhpStorm has to index. A typical Magento 2 project with all dependencies contains over 300,000 files in the vendor directory. The single most effective measure is marking vendor as a Library Root instead of a normal project folder. Library roots are indexed (navigation and autocompletion work), but PhpStorm does not run project inspections on them, which drastically reduces continuous background analysis.

Another Magento specific optimization: restrict the PHP scope for inspections to app/code and the theme directory. Under Settings → Editor → Inspections a scope can be configured for each inspection. If you only want to inspect your own code, create a scope "Project without vendor" and apply all expensive inspections (PHP compatibility, PHPDoc completeness, unused imports) only to that scope. This reduces the amount analyzed from 300,000 to typically 2,000 to 5,000 of your own PHP files.

9. Measures compared by impact

Not all performance measures are equally effective. The following table ranks the described optimizations by their typical impact and the effort required to implement them.

The key insight from the comparison: index excludes and heap size have the biggest effect for the least effort. If you can only implement one measure, start with these two. Disabling plugins has a noticeable but less frequent direct effect, it pays off mainly when the profiler has identified a particular plugin as the cause.

10. Summary

PhpStorm performance problems on large PHP projects have the same causes in nearly all cases: too many files in the index, too little heap memory and too many active plugins. The order of measures matters: first configure index excludes (pub/static, var, generated), then adjust the heap size, then audit plugins. Only after that do finer optimizations such as JVM tuning, selective inspection configuration and library root markers pay off.

The built in profiler makes performance problems visible and replaces guesswork with facts. If a particular plugin or inspection consumes 80% of the CPU time, the solution is clear: disable that plugin or restrict that inspection. Without the profiler, you could spend hours tuning the wrong options. With it, you find the cause within minutes.

11. FAQ: PhpStorm performance problems