Je ne connais pas l'ensemble de l'industrie, mais dans mon cas—où le code n'est pas trop bâclé de base—le gros du travail d'optimisation ce n'est pas tant sur le temps d'exécution du code mais sur la limitation du garbage pour empêcher au maximum le GC de se déclencher et stopper le process pendant 10s. Une grosse source de garbage au début était... les logs.
Alors certes le temps d'exécution a son importance, mais le gros problème est surtout le JIT qui ne permet d'atteindre le temps optimal qu'au bout d'un certain nombre d'itérations. Idéalement il faudrait donc préchauffer la JVM pour que les premiers appels ne prennent pas 400ms et les suivants 2 ; et que tous les appels prennent 2ms.
Ces deux problèmes (temps de pause et warmup) c'est vraiment quelque chose qu'une JVM magique peut significativement changer. Alors j'imagine qu'il ne faut pas jeter les JVM alternatives à la poubelle sans avoir testé dans son cas particulier (et les chiffres dépendent probablement de l'application testée).
Et si cette JVM de course augmentait tellement les performances des applications que son coût serait inférieure au temps nécessaire à optimiser le code ?
L'argument original reste bancal à mon sens, la perf c'est un process en soi : il faut se donner des objectifs, les tester régulièrement pour vérifier qu'un changement dans le code ne le casse pas, etc. donc ça a un coût permanent, quelque soit la jvm utilisée.
[^] # Re: Argument fallacieux
Posté par Starch . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 4. Dernière modification le 21 août 2018 à 10:25.
Je ne connais pas l'ensemble de l'industrie, mais dans mon cas—où le code n'est pas trop bâclé de base—le gros du travail d'optimisation ce n'est pas tant sur le temps d'exécution du code mais sur la limitation du garbage pour empêcher au maximum le GC de se déclencher et stopper le process pendant 10s. Une grosse source de garbage au début était... les logs.
Alors certes le temps d'exécution a son importance, mais le gros problème est surtout le JIT qui ne permet d'atteindre le temps optimal qu'au bout d'un certain nombre d'itérations. Idéalement il faudrait donc préchauffer la JVM pour que les premiers appels ne prennent pas 400ms et les suivants 2 ; et que tous les appels prennent 2ms.
Ces deux problèmes (temps de pause et warmup) c'est vraiment quelque chose qu'une JVM magique peut significativement changer. Alors j'imagine qu'il ne faut pas jeter les JVM alternatives à la poubelle sans avoir testé dans son cas particulier (et les chiffres dépendent probablement de l'application testée).
L'argument original reste bancal à mon sens, la perf c'est un process en soi : il faut se donner des objectifs, les tester régulièrement pour vérifier qu'un changement dans le code ne le casse pas, etc. donc ça a un coût permanent, quelque soit la jvm utilisée.