"C'est à la fin d'un projet qu'il faut voir si les perfs conviennent ou non."
Il vaut toujours mieux un code maintenable à un code rapide, c'est évident. Mais si le code est énorme, et que la lenteur est du à des erreurs d'architectures, c'est impossible de corriger.
Le cas typique est le lancement de fonctions de rafraichissement ou de mise à jour qui nécessite la relecture de toutes les données. Avec de grosses données, c'est la catastrophe.
[^] # Re: attention au microbenchmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal OpenJDK 8, JEP 142 & False Sharing. Évalué à 4.
"C'est à la fin d'un projet qu'il faut voir si les perfs conviennent ou non."
Il vaut toujours mieux un code maintenable à un code rapide, c'est évident. Mais si le code est énorme, et que la lenteur est du à des erreurs d'architectures, c'est impossible de corriger.
Le cas typique est le lancement de fonctions de rafraichissement ou de mise à jour qui nécessite la relecture de toutes les données. Avec de grosses données, c'est la catastrophe.
"La première sécurité est la liberté"