Why is my converter function running slower than when using the - >> operator?

When solving the problem from Hackkerank ( https://www.hackerrank.com/challenges/string-compression/problem ) I wrote 2 implementations with and without converters.

I expected the converter implementation to be faster than the function chain operator ->> . Unfortunately, according to my mini-standard, the chain operator exceeded the converter 2.5 times.

I thought I should use converters where possible. Or I did not understand the concept of converters correctly?

Time:

"Elapsed time: 0.844459 msecs"

"Elapsed time: 2.697836 ms"

code:

 (defn string-compression-2 [s] (->> s (partition-by identity) (mapcat #(if (> (count %) 1) (list (first %) (count %)) (list (first %)))) (apply str))) (def xform-str-compr (comp (partition-by identity) (mapcat #(if (> (count %) 1) (list (first %) (count %)) (list (first %)))))) (defn string-compression-3 [s] (transduce xform-str-compr str s)) (time (string-compression-2 "aaabccdddd")) (time (string-compression-3 "aaabccdddd")) 
+5
source share
1 answer

The converter version seems faster, according to Criterium :

 (crit/quick-bench (string-compression-2 "aaabccdddd")) Execution time mean : 6.150477 ยตs Execution time std-deviation : 246.740784 ns Execution time lower quantile : 5.769961 ยตs ( 2.5%) Execution time upper quantile : 6.398563 ยตs (97.5%) Overhead used : 1.620718 ns (crit/quick-bench (string-compression-3 "aaabccdddd")) Execution time mean : 2.533919 ยตs Execution time std-deviation : 157.594154 ns Execution time lower quantile : 2.341610 ยตs ( 2.5%) Execution time upper quantile : 2.704182 ยตs (97.5%) Overhead used : 1.620718 ns 

As coredump noted, the sample size of one is not enough to say whether one approach is faster than the other.

+6
source

Source: https://habr.com/ru/post/1275264/


All Articles