>Finallement, on retient :
>- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)
*NON*, il faut choisir l'algorithme le plus simple, le plus maintenable en mettant une interface bien propre.
Mesurer les temps d'executions.
Si ce n'est pas suffisant: optimiser la ou c'est nécéssaire.
Le choix du language est plus difficile au niveau performance car si tu prends un langage lent genre Ruby, il y a aussi le risque du probleme des "milles coupures": pas un point chaud à optimiser (ça c'est pas trop compliqué) mais être lent partout et la, il n'y a plus qu'à réécrire.
Mais surtout il faut trouver un language accepté par ton chef donc D, Scala, Ruby, Limbo et autre Erlang, ce n'est pas gagné..
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par reno . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 2.
>- Il faut toujours choisir l'algorithme le moins naïf, si ce n'est pas couteux pour la conception du programme (shell sort contre bubble sort par ex pour 2 tri sans appels de piles)
*NON*, il faut choisir l'algorithme le plus simple, le plus maintenable en mettant une interface bien propre.
Mesurer les temps d'executions.
Si ce n'est pas suffisant: optimiser la ou c'est nécéssaire.
Le choix du language est plus difficile au niveau performance car si tu prends un langage lent genre Ruby, il y a aussi le risque du probleme des "milles coupures": pas un point chaud à optimiser (ça c'est pas trop compliqué) mais être lent partout et la, il n'y a plus qu'à réécrire.
Mais surtout il faut trouver un language accepté par ton chef donc D, Scala, Ruby, Limbo et autre Erlang, ce n'est pas gagné..