La seule et unique raison de personnaliser les paramètres de mémoire d'IntelliJ IDEA

Ne soyez pas un Scrooge et donnez à votre IDE un peu plus de mémoire

Hier, nous avons discuté de la personnalisation des paramètres de mémoire dans IntelliJ IDEA. Il est apparu que certaines personnes ne le faisaient pas, certaines personnes (comme moi) utilisaient un simple jeu de modifications et certains développeurs élaboraient une configuration sophistiquée et sophistiquée qui répondait à leurs besoins. Alors que je travaillais pour un projet en cours, j’ai dû faire face à plusieurs petits projets de microservices et à un projet plus ancien, l’une des activités principales du client. Et après avoir appliqué certains changements, j'ai constaté une nette amélioration en termes de rapidité et de réactivité de l'IDE. Mais à cette époque, je ne mesurais pas ce qui avait changé exactement, c’était seulement une observation subjective que “IDEA est maintenant plus rapide”.

Mais au cours de cette discussion, un des développeurs travaillant pour le même client (merci Yuri) m'a envoyé ses paramètres et j'ai été vraiment dépassé par leur niveau de complexité. J'étais heureux avec ma propre configuration, mais j'étais également curieux de savoir comment ces paramètres complètement différents se comparaient les uns aux autres et aussi comment ils se comparaient aux valeurs par défaut fournies par JetBrains. Donc, après discussion avec Yuri, j'ai su que c'était un bon matériel pour un article de blog.

Objectif

Mon plan est de comparer la performance de différents paramètres de mémoire IDEA dans un scénario proche de mon utilisation quotidienne (charger un grand projet, charger deux ou trois microservices, actualiser un grand projet après une vérification hypothétique). git pull), puis choisissez les paramètres les plus optimaux en termes de consommation de mémoire et d’amélioration de la vitesse.

Machine d'essai et projets

Portable: MacBook Pro Retina, Intel Core i7 à 2,3 GHz, 16 Go, 1 600 MHz DDR3, Disque SSD, OS X Yosemite

Projets

• Big Project – monolithe, 700 000 lignes de code (Java 8 et Groovy), modules 303 Gradle
• Deux microservices – petits projets avec 10 000 à 20 000 lignes de code (Java 8 et Groovy), chacun avec un module Gradle

Scénario de test

1. Fermer tous les projets dans Idea
2. Mettez les paramètres à tester dans le fichier idea.vmoptions
3. Réinitialiser mon ordinateur portable
4. Après un démarrage, fermez tous les programmes indépendants (communicateurs, etc.)
5. Idée ouverte (temps de mesure)
6. Open Big Project (temps de mesure)
7. Vérifiez jstat -gcutil
8. Ouvrez deux autres projets: Microservice One et Microservice Two (temps de mesure)
9. Vérifiez jstat -gcutil
10. Retournez à Big Project et cliquez sur le bouton “Refresh Gradle project” (mesure du temps).
11. Vérifiez jstat -gcutil

Qu'est-ce que jstat -gcutil

Jstat est un outil disponible dans votre JDK pour surveiller les statistiques de JVM et de Garbage Collector. Il y a beaucoup d'options différentes pour collecter diverses données (la documentation complète est ici), mais une seule nous intéresse: -gcutil:

-gcutil - Résumé des statistiques de la récupération de place.

S0: utilisation de l'espace 0 du survivant en pourcentage de la capacité actuelle de l'espace.
S1: utilisation de l'espace 1 du survivant en pourcentage de la capacité actuelle de l'espace.
E: utilisation de l'espace Eden en pourcentage de la capacité actuelle de l'espace.
O: Utilisation de l'ancien espace en pourcentage de la capacité actuelle de l'espace.
M: utilisation des méta-espaces en pourcentage de la capacité actuelle de l'espace.
CCS: Utilisation de l'espace de classes compressé en pourcentage.
YGC: Nombre d'événements GC de la nouvelle génération.
YGCT: heure de la collecte des ordures de la jeune génération.
FGC: Nombre d'événements complets du GC.
FGCT: heure de récupération complète des ordures.
GCT: Temps total de ramassage des ordures.

Exemple de sortie de cette commande ressemble à ceci:

S0 S1 E O M CCS YG YGCT FGC FGCT GCT
89.70 0.00 81.26 74.27 95.68 91.76 40 2.444 14 0.715 3.159

Dans ce billet, les paramètres les plus importants sont le nombre d’événements GC (YGC et FGC) et les temps de collecte (YGCT et FGCT).

Paramètres testés

J'ai testé quatre réglages différents, pour faciliter la lecture, un nom a été attribué à chacun d'entre eux.

Par défaut (gris)

Ce sont des paramètres intégrés fournis par JetBrains, mais IDEA 15 les utilise:

1
2
3
4
5

-Xms128m
-Xmx750m
-XX: MaxPermSize = 350m
-XX: ReservedCodeCacheSize = 240m
-XX: + UseCompressedOops

Gros rouge)

4096 Mo pour Xmx et 1024 Mo pour ReservedCodeCacheSize, c’est beaucoup de mémoire.

1
2
3
4

-Xms1024m
-Xmx4096m
-XX: ReservedCodeCacheSize = 1024m
-XX: + UseCompressedOops

Équilibré (bleu)

2 Go pour Xmx et 2 Go pour Xms, approche plus équilibrée de la consommation de mémoire

1
2
3
4

-Xms2g
-Xmx2g
-XX: ReservedCodeCacheSize = 1024m
-XX: + UseCompressedOops

Sophistiqué (orange)

Comme ci-dessus, 2 Go pour Xmx et 2 Go pour Xms, mais un garbage collector différent est spécifié et de nombreux indicateurs différents pour la gestion du GC et de la mémoire. J'ai reçu ces paramètres de Yuri.

1
2
3
4
5
6
7
8
9
dix
11
12
13
14
15
16
17

-serveur
-Xms2g
-Xmx2g
-XX: NewRatio = 3
-Xss16m
-XX: + UseConcMarkSweepGC
-XX: + CMSParallelRemarkEnabled
-XX: ConcGCThreads = 4
-XX: ReservedCodeCacheSize = 240m
-XX: + AlwaysPreTouch
-XX: + Compilation à plusieurs niveaux
-XX: + UseCompressedOops
-XX: SoftRefLRUPolicyMSPerMB = 50
-Dsun.io.useCanonCaches = false
-Djava.net.preferIPv4Stack = true
-Djsse.enableSNIExtension = false
-un

Ce sont donc nos configurations de test. Pour réaliser nos scénarios de test, nous devons créer un fichier. idée.vmoptions sous ~ / Library / Preferences / IntelliJIdea15 / (il est spécifique à Mac OS, pour voir comment modifier ces paramètres pour votre système d'exploitation, consultez cet article).

Il est maintenant temps de réaliser nos scénarios de test et de comparer les résultats.

Résultats

Heure de démarrage de l'idée

Comme vous pouvez le constater, le temps de démarrage ne dépend pas des paramètres de la mémoire. Le temps de démarrage d'une idée est d'environ 10 secondes pour tous les scénarios de test, peu importe la quantité de mémoire allouée. Et ce n’est pas une surprise, car ces paramètres ne devraient pas affecter le comportement des applications à un stade aussi précoce.

Il est temps de charger le grand projet

Ok, il est maintenant temps de charger notre Monolith et ses 700 000 lignes de code.

Enfin, il y a quelques différences. Les paramètres par défaut sont presque trois fois moins performants que les autres. Apparemment, si grande base de code a besoin de plus de mémoire 🙂 Et si nous exécutons

1

jstat -gcutil 

nous remarquerons que Garbage Collector était vraiment très occupé avec les paramètres par défaut lorsque nous le comparons à d’autres configurations.

Non seulement le temps total passé par le GC à libérer de la mémoire est considérablement plus élevé (environ 50 fois plus), mais le temps d'exécution moyen du Full GC est également beaucoup plus long. Les longues périodes consacrées aux GC complets sont la principale cause de la faible réactivité de notre IDE.

Ouverture de deux microservices dans IDEA

Bien, notre monolith est chargé mais nous devons ajouter du code à deux microservices plus petits. Alors ouvrons-les dans IDEA et comparons les temps totaux.

Dans ce scénario de test, nous voyons que les différences sont toujours visibles et Sophistiqué gagne ici, Défaut est loin derrière le reste.

jstat -gcutil encore

Après avoir chargé deux microservices, nous pouvons vérifier les performances de Garbage Collectors avec trois projets ouverts. Nous pouvons constater que trois paramètres personnalisés se ressemblent presque et que les résultats des paramètres par défaut sont très, très médiocres.

Dernière étape: recharger le monolithe

Nous avons donc codé pendant un moment et nous devons maintenant récupérer la dernière version de The Big Project du référentiel, puis actualiser Gradle Project afin que IDEA puisse voir toutes les nouvelles classes, etc.

Note importante: La barre pour la configuration par défaut est si élevée car IDEA est tombé en panne lors de l'actualisation et je ne pouvais pas mesurer le temps réel. La mémoire simplement affectée n'était pas suffisante pour effectuer cette opération.

Mais en regardant les trois meilleurs, nous voyons que Big settings a actualisé le projet dans les plus brefs délais, de sorte que la plus grande mémoire affectée aide un peu ici.

jstat -gcutil pour la dernière fois

IDEA n’ayant pas pu actualiser le projet avec Défaut paramètres, ils ne sont pas inclus dans cette mesure.

Dans ces derniers graphiques, nous voyons que les différences entre les temps totaux sont assez faibles, mais le simple GC intégral est le plus rapide avec Gros paramètres appliqués. Encore une fois, il semble que Xmx de très grande taille aide un peu plus en termes de réactivité.

Résumé

Dans cette courte expérience, j'ai essayé de tester tout ce que nous pouvions gagner en personnalisant les paramètres de mémoire d'IntelliJ IDEA. Il semble que même quelques ajustements simples puissent considérablement améliorer les performances de notre IDE et accélérer notre travail. Bien sûr, plus vous affectez de mémoire, plus vous obtiendrez de meilleurs résultats, mais nous utilisons IDE pour de nombreuses applications différentes qui consomment également de la mémoire. Notre objectif devrait donc être de trouver un équilibre entre gain de performance et consommation de mémoire. Je pense que dans la plupart des cas, le réglage Xmx valoriser entre 2g et 3g est la meilleure approche. Si vous avez un peu plus de temps, vous pouvez utiliser jstat et jvisualm pour vérifier l’incidence de la modification de différents indicateurs de machine virtuelle sur les performances et l’encombrement de la mémoire.

Et vous?

Et vous? Quelle est votre configuration idea.vmoptions? Avez-vous d'autres moyens d'améliorer les performances d'InteliJ IDEA?