Discussion :

[Franck SORIANO]

Ah oui, c'est vrai, il y a eu une autre fois. Là c'était un concours d'optimisation en Java pour la résolution de Sudoku... J'ai battu le prof

Oui, je me souviens avoir lu ton doc. Si je me souviens bien, tu déclenchais des exceptions pour arrêter la recherche d'une branche identifiée comme étant une impasse.
Tu mettais combien de temps déjà pour résoudre AI-Escargot ? Tu as regardé les résultats du défi ?

Là où il y a un malentendu, à mon avis, c'est ce que nous appelons de l'optimisation. Pour moi, "réfléchir 30s pour ne pas écrire un non sens en termes de perfs", ce n'est pas ce que j'appelle habituellement de l'optimisation. C'est du... ben du bon sens, justement. L'optimisation au sens où je l'entends, c'est déjà le côté pente raide de l'exponentielle dont tu parles

Donc en fait, il me semble qu'au final, nous sommes parfaitement d'accord l'un avec l'autre.

Je sais. Mais ce que je veux faire remarquer c'est qu'à force de dire "les perfs et l'optimisation on s'en fou, on verra ça dans un deuxème temps" on se retrouve rapidement à faire n'importe quoi. Et ayant une bonne dizaine d'années d'expérience professionnelle, je peux te garantir que quand je dis n'importe quoi, c'est vraiment n'importe quoi !
Genre j'ai une boucle sur 50 lignes de facture. Je fais un calcul (toujours le même) qui consiste à multiplier une valeur par une constante dans une table de la base de données. Je fais ce calcul trois fois par ligne.
Et bien au lieu de charger la constante avant la boucle, je fais la requête SQL à chaque fois que j'utilise la valeur !
Tout ça parce que c'est plus lisible d'écrire une fonction qui renvoie la valeur de la constante que de faire la requête. Et que mémoriser le résultat de la fonction dans une variable, ça n'apporte rien question lisibilité...
Sauf qu'en cachant le code de cette façon, on oublie qu'il fait quelque chose...
En 3 lignes, le développeur en question a ruiné deux ans d'efforts d'optimisation. Comme ça venait en même temps qu'une évolution fonctionnelle, ils ont tous dis "c'est lent, c'est normal, c'est ce qu'on nous a demandé, on verra les perfs après si les utilisateurs gueules".
Ils ont juste oublié que les utilisateurs se plaignaient déjà des perfs...

[sjrd]

Oui, je me souviens avoir lu ton doc. Si je me souviens bien, tu déclenchais des exceptions pour arrêter la recherche d'une branche identifiée comme étant une impasse.

En effet, mais aussi pour court-circuiter les calculs lorsque je trouvais une valeur qui était à coup sûr la bonne.

Donc, dans ce projet, j'ai en fait utilisé les exceptions pour améliorer les performances. Comme quoi, les exceptions ne sont pas en soi des gouffres à perf ; c'est la façon dont on les utilise qui fait ça.

Tu mettais combien de temps déjà pour résoudre AI-Escargot ? Tu as regardé les résultats du défi ?

Bah, je mettais en-dessous des 17 ms, comme toute grille à solution unique. Mais les mesures de Java n'étaient pas plus précises que ça.

De toutes façons, ce n'était pas vraiment comparable au défi, parce que nous devions surtout gérer les grilles à solutions multiples... Ce qui était la véritable difficulté question performances.

[Franck SORIANO]

Donc, dans ce projet, j'ai en fait utilisé les exceptions pour améliorer les performances.

La question est de savoir à partir de quand on parle "d'amélioration" plutôt que de "correction d'une anomalie grâve".
Lorsque les utilisateurs hurlent parce que ton appli se traine, et que tu débarques avec une nouvelle version qui corrige les pb de lenteurs, ils ne te disent pas "super tu as optimisé ton appli", mais plutôt "tu as enfin corriger tes c...".
C'est la question du "en dessous de 0" dont je parlais précédemment.

Bah, je mettais en-dessous des 17 ms, comme toute grille à solution unique. Mais les mesures de Java n'étaient pas plus précises que ça.

Elle est facile celle là .

De toutes façons, ce n'était pas vraiment comparable au défi, parce que nous devions surtout gérer les grilles à solutions multiples... Ce qui était la véritable difficulté question performances.

Ben en fait le défi était censé résoudre les grilles à solutions multiples. Pas grand monde ne l'a fait mais c'était bien le sujet.
De plus, ce n'est pas vraiment une difficulté. Au contraire, c'est plutôt une simplification. Au lieu de devoir orienter la recherche pour trouver la bonne solution en premier, il suffit de la laisser tourner jusqu'à avoir explorer toutes les branches, l'ordre de l'exploration n'ayant plus d'importance...

[sjrd]

Ben en fait le défi était censé résoudre les grilles à solutions multiples. Pas grand monde ne l'a fait mais c'était bien le sujet.
De plus, ce n'est pas vraiment une difficulté. Au contraire, c'est plutôt une simplification. Au lieu de devoir orienter la recherche pour trouver la bonne solution en premier, il suffit de la laisser tourner jusqu'à avoir explorer toutes les branches, l'ordre de l'exploration n'ayant plus d'importance...

Simplification pour écrire l'algo, oui. Mais c'est quand même avec les solutions multiples qu'arrivent les considérations de performances.
Parce qu'avec une seule solution, je parie que même un algo hautement naîf (bon pas un brute-force, quand même, hein ) trouve la solution en moins d'une seconde.

Dit autrement, tant qu'on n'a qu'une seule solution, c'est pas la peine d'attaquer la pente raide. Mais s'il faut gérer des milliers de solution, et les trouver toutes, alors là la pente raide commence à se faire très tentante