Closed vrom911 closed 7 years ago
@Martoon-00 , could you please review the (...)
(super composition) benchmarks? It seems that it's very fast and all is within the limits of error.
@Martoon-00 here is the result I received:
It still works okay when I'm using functions receiving many args (I used 5) : 1.071 ns
and 1.072 ns
super and normal composition accordingly. But the interesting thing I discovered is when you don't write down the function type for super composition it works very slow 356.6 ns
((...)/5args/unty
benchmark). It seems it inferences very polymorphic type which affects optimizations.. But when types are explicitly specified no difference is noticed.
Very interesting results! Glad to know that it can work as fast as with writing it in normal way 🙂
Could you please try one more thing: function without type, but with INLINE
pragma. My guess is that, ...
already has this pragma, so when type of function calling it is known, ...
call is rewritten in normal way by GHC. However when type is unknown then ...
can not be inlined, and compiler may suggest not to inline unty5args
itself as well, thus we get such drawdown
@Martoon-00 done! It works as fast as super typed version.
Great! I suppose these results are worth mentioning in haddoc to '(...)' eventually. Thanks for your thorough work on this!
I created benchmarks for concatMap
. It turns out that concatMapM
in Identity
is 3x times slower than concatMap
even on not big tests. Is that what was on your mind, @Martoon-00 ?
Wow, that's worth investigating. Thanks for finding this issue!
@vrom911 Thanks for your amazing contribution in this issue! I really appreciate your effort for our benchmarks. I ran benchmarks and saw results for nub
and other functions (following your discussion with@Martoon-00). Looks great! And I will create new issues by results of this PR.
I made benchmarks on lists where numbers are not greater than 100 (
"small"
) and where I have list consist of numbers from 1 ton
repeated twice ("big"
).