But structs are generally much nicer to work with because they are maps and not tuples. For example, IIRC cowboy 2.0 moved from using records to represent its Req object to maps. But from reading its (as well as ranch and cowlib) source code I got a feeling that cowboy was striving for completeness and ease of use rather than performance.
case foo do
%{bar: bar} -> bar
%{} -> :erlang.raise({:badkey, :bar, foo})
_ -> apply(foo, :bar, [])
end
I was mostly writing about memory size, which has some less direct effect on the applications triggering less GC, sending binaries between processes without copying, allowing for more structural sharing with sub binaries, etc. The difference is actually not that big on OTP 20 already when iterating over bytes (I think there are some things that should make binaries even faster on OTP 21).
Operating System: macOS
CPU Information: Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Number of Available Cores: 8
Available memory: 16 GB
Elixir 1.7.0-dev
Erlang 20.3
Benchmark suite executing with the following configuration:
warmup: 2 s
time: 5 s
parallel: 1
inputs: none specified
Estimated total run time: 21 s
Name ips average deviation median 99th %
list 265.45 K 3.77 μs ±19.34% 3.60 μs 6.90 μs
binary_byte 210.06 K 4.76 μs ±25.28% 4.40 μs 8.60 μs
binary_utf8 93.43 K 10.70 μs ±30.39% 10 μs 20 μs
Comparison:
list 265.45 K
binary_byte 210.06 K - 1.26x slower
binary_utf8 93.43 K - 2.84x slower
The Google Groups thread seems to imply that structs/maps will be more performant when doing the typical pattern match and have benefits wrt polymorphism and protocol support. It seems the only thing Records excel at are access within tight loops.
If I understand this correctly, it seems that Structs would outperform Records for the vast majority of general state holding problems. Like the state of a Cowboy Req object and nearly every GenServer.
Like the state of a Cowboy Req object and nearly every GenServer.
Changing deeply nested values in tuples is more expensive, I think, than in maps. That’s the only performance benefit maps have over tuples that I know of.
If you only build a tuple once (like it could be done with cowboy req), and then use it just to read values from it, it should be more efficient than a map.
You can benchmark your own use case with benchee both using maps and tuples and see for yourself.
defrecord Student, [:first_name, :last_name]
def name(record) do
"#{record.first_name} #{record.last_name}"
end
The function above would also work on any record that contains the fields first_name and last_name. Its implementation relies on the fact we can call a function on a tuple like {Student, “josé”, “valim”}. So when you defined a record, we automatically defined functions for all of its fields. This added runtime behaviour to records but, because this relies on a tuple dispatch, it was actually slower than accessing or matching fields in a map!
This added runtime behaviour to records but, because this relies on a tuple dispatch, it was actually slower than accessing or matching fields in a map!
I don’t think it works like this anymore. You can extract the values you need in a single pattern match.
def name(student(first_name: first_name, last_name: last_name)) do
# ...
end
unless elixir does something funny, it should be the same as
def name({:student, first_name, last_name}) do
# ...
end
This kind of pattern matching (first element is an atom) is somewhat optimized (since records are used quite often in erlang) and, at least in my experience, much faster than pattern matching maps.
That is why we should get different syntax for accesses, like what about using the OCaml’y # as struct access (not literally proposing # as it is a comment, but just as an example of why not use different syntax for different type, or if Elixir was actually typed then you could use the same syntax as there is no ambiguity then).
OCaml uses M.f to access a module namespace (capitalized initial character like Elixir), and it uses s.f to access a struct (when the left start does not start with a capitalized initial character, also like elixir). It uses a.[0] for array access. It uses o#m for object access. Among a few others. You can easily tell the type of something by the operators used even without typing declarations.
Ah yes, entirely true.
Would be nice. Though I did testing not long ago about iterating over a charlist and over a binary and it was faster for me to :erlang.string_to_binary and operate over the list then it was to iterate over the binary at the time (it was not super-long stuff, like 30 chars or so).
Ah yep, your results is about on par with the differences that I saw too.
Hmm, I wouldn’t think that would be true but would need to benchmark… A record is nothing but a tuple, so a RecordName(blah, blee, blorp) literally is just {RecordName, blah, blee, blorp}, the 4-tuple, and tuple access and matching is FAST, like nothing faster kind of fast. However rebuilding it and updating it I could see as slower than updating maps on larger sized records/tuples (though not smaller).
Not deeply nested, but rather larger tuples in general.
Yep, Tuples are O(1) access, Maps are O(N).
That was purely because Elixir used a really really bad access pattern for Records. If instead it copied the OCaml way (which requires types) or the Haskell way (which, interestingly, does not require types), then it would be perfectly efficient. But putting it as a . access was really really bad and I don’t know why that would have ever been chosen for records, it is just really really bad.
Those would be identical I’d think, that is how erlang compiles it anyway.
Is there official Elixir documentation that enumerates the time complexity for Elixir’s container types? I was going through the docs for both Record and Map and neither seems to state the time complexity of their various functions.
Also, does function head matching have the same performance? The info on reddit seems to imply that matches are always O(1).
Maps have actually two representations depending on the size. Small maps (less than 32 keys) are represented as two sorted arrays - one for keys and one for values. Accessing a key in such a map involves a linear search (and a linear search is much faster than a binary search since the size is so small). Depending on how you look at it, you might say that’s O(n) since it depends on the map size, or O(1) since the worst case is O(32), which is O(1) - the big O notation is not very helpful when talking about small data structures, especially with cache locality and branch prediction effects, you can get significantly different results from what you’d expect by a simple complexity analysis.
Large maps are represented as HAMT and the access is O(log n) - the “forking” factor of the maps is 32, so even very big maps are rather shallow and rarely involve more than 3 levels (32k items).
Anyway, maps are superior to me because of one simple thing - I can read them. Records are terrible in that regard - you get a tagged tuple and you have no idea what the fields mean. Debugging with records is a significantly worse experience and takes much longer. I would reach for records in the tightest loops of the program, where I need some “lolspeed”, but for everything else, maps and structs are plenty fast.
Comparing the speed of deeply nested tuples/records and flat maps/structs seems a bit strange. However you look at it with records you access a specific field in the tuple while with maps you have to search for the right field. Check @michalmuskala description of the internals.
Yes, using for records/tuples for small sizes, currently less than 32, is faster than maps but maps are definitely faster for large sizes. It all depends on how big your records/structs are. Maps/structs do use more memory than tuples/records as they include the names of the keys though that definitely does make them more readable at runtime.
If you check out this post Elixir vs. Erlang benchmarks - is one faster than the other? it describes that the internal implementation of maps varies depending on their size. For small maps, < 32, they are basically a pair of arrays containing the keys and the values. So for updating an existing key it would at least mean copying the value array while for adding/deleting a key it would mean copying both arrays. I am guessing they can share unchanged arrays.
For larger maps it is more complex and how long and how wide the path will of course affect how copying there needs to be done. Here again I am guessing they can share unchanged parts.
I am also guessing that they have tested to find the best methods and limits.
However you do it with maps you still have to search for the right place at runtime while with records the calculation is done at compile time. There is not much you can do about that as that is a property of maps. When maps were introduced some in the Erlang community said that now we can get rid of records and use maps instead, but they don’t really solve the same problem.
Of course both records and structs are a way of adding user-defined data types to a system which doesn’t have them.
That is only because of the language syntactical constructs. If it use, say, Haskell’y record accessors then it would still be readable (although a function call instead of a . access, I.E. instead of blah.bloop it would instead of be bloop(blah), which would remove a case from . accesses thus making it near imperceptibly faster ^.^).
I wish the Record module in Elixir was implemented that way, it’s pretty close as it is, but not ‘quite’ there (it likes the KW access of a single function instead).
As for debugging, it would not be hard to in the inspector check if the first element of a tuple is an atom, and if it is check if it is a valid module, and if it is then format it like a record from that module (there could be a default-implemented to_string/1 function and/or to_repr/1 on record modules for example). This seems purely a language restriction and not something intrinsic to them being records as it is an Erlang standard ‘construct’ (not type though).
This right here. All cases of Elixir ‘Structs’ are small and thus better suited for an internal implementation as records (especially as I really exceptionally don’t like the ruby-ish style of random field-name accessing without knowing the proper and full type of something).
It’s really like the difference between OCaml Records and Objects, an OCaml record is, internally, just a C-like struct, no names, tightly packed, where an OCaml object is internally a dictionary, thus slower but more introspectable, and yet Objects in OCaml are touched in easily less than 1% of all library code just because Records are so easy to use, and the syntactical differences between them is a single character for usage, although Objects are a bit more verbose to define compared to records (opposite in Elixir where their definitions are almost identical but their usages are very different), however OCaml’s objects can fulfill multiple object implementations at once (think Rust/Go/Etc… style traits and implementations). Syntax is what makes all the difference, and the reason maps are so often used in Elixir compared to tuples/records is that the language support for records is and has been bad compared to maps (even something as basic is checking if the first element is a module-atom and checking that the record is valid as such to display is better, of which the inspect protocol already does a lot of special-casing like that so there was no reason not to…).
For larger non-structs, like actually storing larger amounts of data, I’d use maps the whole way. It’s just a thing of using the right type for the right code, and for small static things static records work far better, where maps are better for larger and/or dynamic work.
We need a BEAM VM that supports type declarations, falling back to an unchecked dynamic type that everything is be default, would be a huge boon for adding typed languages on the BEAM and especially for generating better internal code for when types are already known (like if you know a couple bindings are unsigned integers of 32-bit width and you add them, well that’s just a simple single assembly instruction then, no boxing or anything needed until they get passed back to 'dynamic’lly typed code, kind of like ASM.js of the javascript world, even matchers and guards would be able to infer a lot of typing around otherwise dynamic to make their internal bits more efficient).
According to some comments, there’s “no difference,” but clearly there is. I’m interested in using Erlang and/or Elixir in production. However, I’d like to get some straightforward answers. I will continue to read through the comments here.
When you say there are no differences, do you mean no as in “none” or no as in “some, but they’re not significant.” If the latter is the case, do you have any recommendations for any benchmarks I could view?
Thank you! I know this is a couple years old, but yeah ha. Just to add, I’m new to the community and I really enjoy Erlang and Elixir.
Hi thanks for taking the time to respond. I guess I meant your comment said there were no differences, but reading through other comments there seems to be some differences. After reading the comments more carefully I can see that the situation is nuanced in specific cases.
For context, I’m trying to build out a list of some pros and cons of using Elixir vs Erlang (in a context where syntax is not a deciding factor). I’m trying to develop a good answer to, “why use Elixir when you could use Erlang directly?”
Your comment was pretty concise and says about what I’d like to say. Do you have any suggestions on how I could show this? E.g. can I compare the byte code of elixir & erlang for similarity? Or would you say if there are any differences, they’re negligible?
When you write literally the same code, you get literally the same bytecode. Examples:
-module(math).
-export([factorial/1]).
factorial(0) ->
1;
factorial(X) when X > 0 ->
X * factorial(X-1).
Will produce exactly the same bytecode as
defmodule Factorial do
def factorial(0), do: 1
def factorial(x) when x > 0, do: x * factorial(x - 1)
end
Literally 100% the same. Now, the Elixir standard library sometimes favors certain patterns of abstractions that provide a negligible, but not technically 0 cost compared to an erlang alternative. So for example:
Enum.map(list, fn x -> x * 2 end)
has 1 function call more over head (1 period, not 1 per item) than:
lists:map(fun(X) -> 2*X end, List).
because the Enum.map function will convert non list things to a list in order to map over them. If it is a list, it will just call that same function, which you can do yourself:
# this is elixir code
:lists.map(fn x -> x * 2 end, items)
and that ^ is again byte for byte identical with the erlang code.
So in terms of which one is faster, what it really boils down to is the approaches that each library takes. Certain things that Elixir macros let you do for example make certain high performance strategies a lot easier or more ergonomic than in erlang, and so it can actually be faster. Other times the desire to create friendly APIs in Elixir can sometimes introduce slightly more indirection, which can introduce small if technically non zero overhead.
Fundamentally though whether your Elixir code has overhead WRT erlang is entirely a question of what Elixir code you write. They compile to time same core structure, and end up as the same bytes.
Well said. Thank you for this, I really appreciate the explanation. You’ve helped a lot! (I feel bad leaving such a short comment given you took the time on a good example, so thanks again! ha)
thanks for taking the time to respond. I guess I meant your comment said there were no differences, but reading through other comments there seems to be 
