Plus que les détails d’implémentation, sur de grands jeux de données, ne serait-ce qu’un truc aussi basique que le tri il y a des algo. qui vont de O(n) à O(n2), les plus rapides en moyenne peuvent être les plus lents en « pire cas ». Il vaut mieux avoir une idée du jeu de donnée à traiter et choisir l’algo. en fonction. À moins de vouloir les tester un à un...
Dans un de mes codes en arbre pour une recherche de voisins il y a un critère pour basculer sur l’algo. brut (pour tous couples test la distance), la différence était sensible lors de mes tests.
« Premature optimization is the root of all evil (or at least most of it) in programming. »
D’où vient cette idée ? J’ai déjà eu l’occasion d’exprimer mon désaccord à ce sujet : lorsque la rapidité une contrainte importante l’optimisation doit être pensée dès la conception. À moins de vouloir refaire le travail deux fois.
Je veux bien que dans un programme complexe, qui invoque multitude d’algo. on va pas chercher la rapidité pour une fonction qui ne s’exécute qu’une fois l’an et il vaut mieux savoir où chercher. Mais la plupart du temps on sait quelle portion de code est incriminée dans un calcul lourd...
[^] # Re: Compréhension
Posté par nicolas . En réponse au journal Programmation : la complexité c'est le mal. Évalué à 1.
« Est-ce que ça ferra une différence sensible ? »
Plus que les détails d’implémentation, sur de grands jeux de données, ne serait-ce qu’un truc aussi basique que le tri il y a des algo. qui vont de O(n) à O(n2), les plus rapides en moyenne peuvent être les plus lents en « pire cas ». Il vaut mieux avoir une idée du jeu de donnée à traiter et choisir l’algo. en fonction. À moins de vouloir les tester un à un...
Dans un de mes codes en arbre pour une recherche de voisins il y a un critère pour basculer sur l’algo. brut (pour tous couples test la distance), la différence était sensible lors de mes tests.
« Premature optimization is the root of all evil (or at least most of it) in programming. »
D’où vient cette idée ? J’ai déjà eu l’occasion d’exprimer mon désaccord à ce sujet : lorsque la rapidité une contrainte importante l’optimisation doit être pensée dès la conception. À moins de vouloir refaire le travail deux fois.
Je veux bien que dans un programme complexe, qui invoque multitude d’algo. on va pas chercher la rapidité pour une fonction qui ne s’exécute qu’une fois l’an et il vaut mieux savoir où chercher. Mais la plupart du temps on sait quelle portion de code est incriminée dans un calcul lourd...