I saw once an Enum.reduce going slower than Enum.map, followed by Enum.into…
kokolegorille
lud
If you want only calculate_total_hours you can call that single function. It may not bee a good idea to bind two independent pieces of logic together, unless you are 100% sure that you will always need to call the two computations. And in that case I would just follow above advice: make it beautiful then move on.
1
al2o3cr
It would take very careful benchmarking to clearly show whether the single reduce is faster or slower than the two passes over the list. My back-of-the-envelope calculation:
Split loops, per element in the list:
- two “get rest of list”
- two map accesses (to get
billorhours) - two additions
Fused loops, per element in the list:
- two map accesses (maybe? Not 100% sure what that pattern-match compiles to)
- one “get rest of list”
- two additions
- one “create new tuple”
Both have two map accesses and two additions per element in the list, as well as a single “get rest of list”; so the budget tradeoff comes down to an additional “get rest of list” versus a “create new tuple” operation.
The BEAM’s optimizer is going to complicate things even further; it might be able to elide most of the cost of “create new tuple” by reusing the tuple passed as an argument - but if the split-loop functions are called more often they might get JITed more aggressively.
2