JetBrains publie une passionnante analyse du concept de Time-to-code dans son IDE phare, IntelliJ IDEA. Le Time-to-Code est la disponibilité réel du projet et donc de l'ensemble des fichiers et des codes liés. Comme le note le post, le scénario standard est : le développeur qui attend l'ouverture du projet. L'IDE doit charger et synchroniser le projet, faire l'indexation et lancer de nombreux traitements et actions que l'on ne voit pas forcément mais qui pénalisent l'ouverture et donc la disponibilité réelle des assets. 

L'éditeur promet une amélioration notable dans les prochaines versions de l'IDE. L'objectif est de réduire le time-to-code et de proposer un IDE plus réactif dès le démarrage. Avant la version 2023.2, l'IDE attendait le synchronisation complète du projet avec Maven ou Gradle tout en faisant l'indexation, la mise en place de la navigation. Il est intéressant de comprendre que l'ouverture d'un projet exige de nombreux actions de la part de la IDE, comme le montre le schéma :

Problème : plus le projet est gros, avec de nombreux fichiers et dépendances, plus le time-to-code est long. Bref, nous avons comme en météo, le temps réel et le temps ressenti. Parfois, il faut plusieurs minutes pour que l'IDE nous donne réellement la main. Les équipes JetBrains avouent qu'améliorer ce démarrage est complexe. Une des pistes est l'optimisation de l'IDE, de son architecture et mieux utiliser le hardware. L'éditeur annonce que les premières optimisations permettent d'améliorer de 25 % le démarrage. Un important travail d'optimisation est fait sur les sous-systèmes de l'IDE. Un des points sensibles est la synchronisation et l'indexation. La version 2023.3 devrait apporter des avancées en utilisant une approche asynchrone. Le nouveau flux de l'IDE donne le schéma suivant :

Le post complet : https://blog.jetbrains.com/idea/2024/11/faster-time-to-code-in-intellij-idea/

Vidéo sur les améliorations des performances de l'IDE et les pistes d'optimisations :