Et encore tu oublies que pas mal d'appli doivent pouvoir tourner sur plusieurs archi mac, PC, téléphone, console... avec des spécificité propres.
Et de toutes façons le problème de l'optimisation n'est même pas là la plupart du temps. Il y a des problèmes beaucoup plus bêtes de mauvais choix de structures de données, ou de mauvaise utilisation de structures de données. Par exemple, faire plusieurs fois de suite une recherche d'un objet dans une map, au lieu de le trouver une fois et de garder une référence. Là on peut avoir des gains de plusieurs dizaines de % de performances, et ça peut être intéressant d'y passer du temps.
Je ne compte plus le nombre de if(map.existe('machin')) { Plop zut = map.get('machin'); } que je trouve dans le code, ou les push_back sauvage dans un vecteur sans avoir réservé la taille nécessaire alors qu'elle est connue.
J'ai aussi trouvé des vérification de clé unique via un parcours dans tableau (non trié cela va de soi), lorsqu'on augmentait un peu la taille des données ça explosait le temps de vérification.
Y'a aussi la manie de garder le xml source de données qu'on reparse à chaque fois pour en récupérer une valeur.
Ouais avant de descendre à l'assembleur, inutile dans l'immense majorité des cas, se pencher sur le code, ses structures, et ses tâches sont bien plus rentable. Si on a pas de quoi instrumenter le code, un bon vieux debugger avec arret, print stack trace de tous les thread, continue, et on recommence, permet de facilement trouver là où l'on passe du temps (a vu de nez) (les mesure exacte ça reste mieux)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Who's that guy ?
Posté par fearan . En réponse au lien Software is Way Less Performant Today. Évalué à 7.
Et encore tu oublies que pas mal d'appli doivent pouvoir tourner sur plusieurs archi mac, PC, téléphone, console... avec des spécificité propres.
Je ne compte plus le nombre de if(map.existe('machin')) { Plop zut = map.get('machin'); } que je trouve dans le code, ou les push_back sauvage dans un vecteur sans avoir réservé la taille nécessaire alors qu'elle est connue.
J'ai aussi trouvé des vérification de clé unique via un parcours dans tableau (non trié cela va de soi), lorsqu'on augmentait un peu la taille des données ça explosait le temps de vérification.
Y'a aussi la manie de garder le xml source de données qu'on reparse à chaque fois pour en récupérer une valeur.
Ouais avant de descendre à l'assembleur, inutile dans l'immense majorité des cas, se pencher sur le code, ses structures, et ses tâches sont bien plus rentable. Si on a pas de quoi instrumenter le code, un bon vieux debugger avec arret, print stack trace de tous les thread, continue, et on recommence, permet de facilement trouver là où l'on passe du temps (a vu de nez) (les mesure exacte ça reste mieux)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent