5 ms·
Because Haskell is evaluated lazily, two maps doesn't imply two iterations over the data. In this case, I would expect only one pass through the data for both
by ddfisher 15y ago
Because Haskell is evaluated lazily, two maps doesn't imply two iterations over the data. In this case, I would expect only one pass through the data for both of the maps.
Out of curiosity, I did a quick criterion benchmark for both functions. Here's the result on a list of 100 elements:
benchmarking spark_mggcl
mean: 49.29483 us, lb 48.77776 us, ub 50.25594 us, ci 0.950
std dev: 3.495423 us, lb 2.140951 us, ub 6.373469 us, ci 0.950
benchmarking spark_ocharles
mean: 60.12347 us, lb 58.95586 us, ub 61.48084 us, ci 0.950
std dev: 6.434853 us, lb 5.529613 us, ub 7.824865 us, ci 0.950
The simpler version appears to be faster.
(As an aside, is there something in particular you dislike about do syntax? I find that it often makes things more readable, though slightly more verbose.)
- ocharles 15y agoI am aware of that, as I said this was more a mental exercise. normalizeMap is harder to understand, but it was interesting to write - it wasn't meant to be a stab at your code or claim it's better :) In terms of do syntax, I try and avoid that because I find it detracts from the overall flow of data. With: "putStrLn . spark . map read =<< getArgs" I find it easy to see that main doesn't do much other than transform the users input. maybe a personal preference thing though...