ahmadferdous
Why should we iterate a list twice to pipe 2 aggregate functions?
I have structs Company, Employee and a list of struct values employees. Struct Employee contains 2 fields - hours and bill.
I need to know total hours and total bill. Should I iterate once (for loop?!) to calculate both together or should we do the following? One of my colleagues say the following is Elixir-y. Why is iterating multiple times encouraged when it is inefficient?
I’m sure there is a good reason and I want to know. Please help me.
def calculate(company) do
company
|> calculate_total_hours()
|> calculate_total_bill()
end
def calculate_total_hours(company) do
total = company.employees
|> Enum.map(& &1.hours)
|> Enum.sum()
%{company | total_hours: total}
end
def calculate_total_bill(company) do
total = company.employees
|> Enum.map(& &1.bill)
|> Enum.sum()
%{company | total_bill: total}
end
EDIT: Updated code
Marked As Solved
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.
Also Liked
gregvaughn
I would likely write this as a single reduce, and I don’t think it suffers elixir-y-ness
{total_hours, total_bill} =
Enum.reduce(company.employees, {0, 0}, fn %{hours: h, bill: b}, {h_acc, b_acc} ->
{h_acc + h, b_acc + b}
end)
aenglisc
“Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!”
tomkonidas
You linked the wrong repo 
al2o3cr
Because it’s easier to read operations that are cleanly decomposed into smaller parts, and because “inefficient” is relative. Traversing a list is a very cheap operation on the BEAM (it’s almost a Lisp under the hood).
It’s hard to say more about the specific example since it doesn’t work: calculate_total_hours returns a number but is piped into a function that expects a list, and it’s unclear where the total hours and total bill should be stored in company.
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.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"