Clojure - optymalizacja gwintowany mapa zmniejszyć

Question

Mam następujący kod:

(defn series-sum 
    "Compute a series : (+ 1 1/4 1/7 1/10 1/13 1/16 ...)" 
    [n] 
    (->> (iterate (partial + 3) 1) 
     (map #(/ 1 %)) 
     (take n) 
     (reduce +) 
     float 
     (format "%.2f") 
     (str))) 

To działa dobrze, poza tym, że to działa w czasie kiedy eksploduje numery uzyskać duże. Na moim komputerze (series-sum 2500) jest może sekunda lub dwie, ale (series-sum 25000) i muszę zabić mojego REPL.

Próbowałem przenieść (take n) w miarę możliwości, ale to nie wystarczy. Czuję, że nie rozumiem czegoś o Clojure, ponieważ nie rozumiem, dlaczego byłoby wolniej (oczekiwałbym, że (series-sum 25000) potraktuje to mniej więcej 10 razy jako (series-sum 2500)).

Istnieje oczywiste rozwiązanie pętli/powtórzenia, aby zoptymalizować to, ale podoba mi się pomysł, aby móc drukować kroki i mieć jeden krok ((take n) wygląda jak docstring).

Jak mogę poprawić wydajność tego kodu przy zachowaniu możliwości debugowania?

Czy mogę jeszcze zmierzyć czas każdego kroku, aby zobaczyć, który zajmuje czas?

Answer 1

tak, jest to istotne dla linku @ zerkms. Mapować do wymiernych, prawdopodobnie powinny lepiej odwzorowane na pływaków:

(defn series-sum 
    "Compute a series : (+ 1 1/4 1/7 1/10 1/13 1/16 ...)" 
    [n] 
    (->> (iterate (partial + 3) 1) 
     (take n) 
     (map #(/ 1.0 %)) 
     (reduce +) 
     (format "%.2f"))) 

teraz działa znacznie szybciej:

user> (time (series-sum 2500000)) 
"Elapsed time: 686.233199 msecs" 
"5,95" 

Answer 2

Dla tego typu operacji matematycznej, informatyki w pętli jest szybsze niż przy użyciu leniwe sekwencje. To jest o rząd wielkości szybciej niż inne odpowiedzi dla mnie:

(defn series-sum 
    [n] 
    (loop [i 0 
     acc 0.0] 
    (if (< i n) 
     (recur (inc i) 
      (+ acc (/ (float 1) (inc (* 3 i))))) 
     (format "%.2f" acc)))) 

Uwaga: nie potrzebujemy str ponieważ format Zwraca ciąg znaków.

Edycja: oczywiście nie jest to główny problem z kodem w pierwotnym pytaniu. Większa część poprawy pochodzi z eliminacji racjonalności, o czym świadczy inna odpowiedź. To tylko kolejna optymalizacja.