If I understand @steven7 correctly, he has 1M inputs which are also huge. Converting each of those inputs to ETS might blow up table space.
Using the table just as ephimeral throwaway conversion might cost to much of time during conversion from one to another.
As I’ve already mentioned in the chat yesterday, I’m still under the assumption that this should be one of the fastest possibilities (in the chat it sounded as if maps as input where given and unchangable):
m1 = %{…}
m2 = %{…}
Enum.reduce(m1, 0, fn {k, v}, sum -> sum + v * (m2[k] || 0) end)
This is optimised on the size of m1, so if m2 is the smaller map, just swap them around.
And I’ll stick to my opinion until I got proven otherwise by benchmarks with data sets of realistical sizes.
And if the input type is not actually fixed to maps but can be changed, and insertion/building time does not matter that much (or data is already sorted anyway), then a pre-sorted proplist like list might actually be the way to go and using algorithms for calculating intersections of sorted listsets to actually calculate the “product” in the accumulator instead of the intersection should be the way to go.
