Un précédent billet aborde le thème des différentes qui peuvent apparaître entre le mode test "Go" d'une application, et sa version compilée pour la plateforme cible. L'important sujet des temps d'exécution n'avait pas été abordé. Il y a pourtant une différence qui peut être importante. Par défaut le mode test "Go" est conçu pour aider le développeur dans ses tâches d'écriture, de tests et de débogage. A l'inverse l'application compilée est optimisée pour les performances, sans information de débogage, afin de proposer une meilleure expérience à l'utilisateur final.
Le mode test "Go" peut donc être moins rapide que l'application compilée.
En mode test par défaut l'exécution du code de l'application se fait sans optimisation (JITc) et s'accompagne de traitements internes au framework en lien avec :
Toutes ses possibilités permettent une mise au point plus rapide, et d'avoir des applications plus robustes en détectant au plus tôt les erreurs. En contrepartie, ses possibilités ont un coût sur le temps d'exécution du mode test "Go". Ce coût est d'ailleurs croissant au fil des versions, puisque les outils d'audits et de mises au point s'ajoutent et sont davantage perfectionnés. Cela explique qu'en mode test "Go" un même traitement comparé entre une version N et une version N-10, puisse être plus rapide en version N-10 !
Bien sûr dans l'application compilée c'est l'inverse. Toutes les possibilités de débogage sont stoppées, et le JITc est activé. Pour un même traitement, les performances sont donc meilleures dans la version compilée, en comparaison du mode test "Go".
Pour des besoins spécifiques, il est possible de privilégier les temps d'exécution du mode test au détriment des outils pour la mise au point, en les désactivant via leur widget dans le tableau de bord :
|