Optim

[cexbrayat]

J'ai jeté un rapide coup d'oeil et je ne sais pas dans quelle mesure la vitesse est importante, mais une tactique simple de cache te ferait gagner pas mal de temps sur scalaskel. Tu n'es aussi pas obligé de passer le resultat en parametre je pense.

[clacote]

Hé hé! J'y ai pensé. Mais c'est déjà trop tard : quand tu réponds juste à toute la série d'un exercice, CodeStory enregistre ton succès et ne te pose plus la question. Et s'ils ont déjà mesuré les temps de réponse, c'est trop tard pour optimiser... Par contre je n'ai pas compris ce que tu voulais dire par "Tu n'es aussi pas obligé de passer le resultat en parametre je pense."

Un vrai problème que j'ai est que j'ai de grosses fuites mémoire, j'imagine sur mon implémentation manuelle du WebServer.

En tout cas, putain, j'y passe des heures. Là je me prends la tête sur les calculs arithmétiques, dont j'étais coupable mais soulagé de déléguer entièrement à Groovy. Et bien ça ne suffit même pas : erreur d'arrondi...

Je pensais d'ailleurs faire un court article de blog sur CodeStory, pour dire combien je trouve le format pertinent : ne sachant pas à l'avance les questions, non seulement tu t'embarques dans une aventure, mais dont le format intrinsèque te pousse au refactoring permanent, puisque tu dois enrichir constamment tes implémentations.

[cexbrayat]

Ha je pensais que une fois que tu avais passé toutes les questions ils relanceraient des tests pour mesurer les perfs de tout le monde.

Ton param result pourrait etre ton retour de change et non pas un parametre.

    public Set<Map<Unite, Integer>> change(final int sum, int[] current, Set<Unite> candidate) {
        Set<Map<Unite, Integer>> results = Sets.newHashSet();
        if (sum == 0) {
            results.add(cleanCopy(current));
        } else {

            Set<Unite> nextCandidate = EnumSet.copyOf(candidate);
            for (Unite unite : candidate) {
                int remaining = sum - unite.getValue();

                if (remaining >= 0) {
                    // We could use one more of this unit
                    current[unite.ordinal()]++;
                    results.addAll(change(remaining, current, nextCandidate));
                    current[unite.ordinal()]--;
                } else {
                    break;
                }
                nextCandidate.remove(unite);
            }
        }
        return results;
    }

[clacote]

Ah OK pour le result. Je pense (à tort peut-être) que c'est beaucoup plus performant sous forme de paramètre : la JVM n'a pas besoin de mettre dans la pile les valeurs de retour, sollicitée massivement avec la récursivité.

[cexbrayat]

Aucune idée, cette considération ne m'avait pas effleurée! Le type de retour était indispensable dans ma logique de mettre du cache.

[clacote]

L'autre méthode change, la seule API publique, a bien une valeur de retour : pas de souci pour mettre en cache! ;)