There's no real practical performance difference between record lookup and map lookup for small numbers of fields. For large numbers of fields, though, there is, because record information is known at compile time while map keys need not be, so maps use a different lookup mechanism than records. But records and maps are not intended as interchangeable replacements, and so comparing them for use cases involving anything more than a small number of fields is pointless IMO; if you know the fields you need at compile time, use records, but if you don't, use maps or another similar mechanism. Because of this, the following focuses only on the differences in performance of looking up one record field and one map key. Let's look at the assembler for two functions, one that accesses a record field and one that accesses a map key. Here are the functions:
The interesting part here starts under {label,2} . The code verifies that the argument is a tuple, then verifies the tuple's arity, and extracts two elements from it. After verifying that the first element of the tuple is equal to the atom foo , it returns the value of the second element, which is record field f . Now let's look at the assembly of the m/1 function:
This code verifies that the argument is a map, then extracts the value associated with map key f . The costs of each function come down to the costs of the assembly instructions. The record function has more instructions but it's likely they're less expensive than the instructions in the map function because all the record information is known at compile time. This is especially true as the key count for the map increases, since that means the get_map_elements call has to potentially wade through more map data to find what it's looking for. We can write functions to call these accessors numerous times, then time the new functions. Here are two sets of recursive functions that call the accessors N times:
We can call these with timer:tc/3 to check the execution time for each function. Let's call each one ten million times, but do so 50 times and take the average execution time. First, the record function:
Calling the map function ten million times averaged 236ms per call. Your mileage will vary of course, as did mine; I observed that running each multiple times sometimes resulted in the record function being faster and sometimes the map function being faster, but neither was ever faster by a large margin. I'd encourage you to do your own measurements, but it seems that there's virtually no performance difference between the two, at least for accessing a single field via pattern matching. As the number of fields increases, though, the difference in performance becomes more apparent: for 10 fields, maps are slower by about 0.5%, and for 50 fields, maps are slower by about 50%. But as I stated up front, I see this as being immaterial, since if you're trying to use records and maps interchangeably you're doing it wrong.
UPDATE: based on the conversation in the comments I clarified the answer to discuss performance differences as the number of fields/keys increases, and to point out that records and maps are not meant to be interchangeable.*
3条答案
按热度按时间uurity8g1#
There's no real practical performance difference between record lookup and map lookup for small numbers of fields. For large numbers of fields, though, there is, because record information is known at compile time while map keys need not be, so maps use a different lookup mechanism than records. But records and maps are not intended as interchangeable replacements, and so comparing them for use cases involving anything more than a small number of fields is pointless IMO; if you know the fields you need at compile time, use records, but if you don't, use maps or another similar mechanism. Because of this, the following focuses only on the differences in performance of looking up one record field and one map key.
Let's look at the assembler for two functions, one that accesses a record field and one that accesses a map key. Here are the functions:
Both use pattern matching to extract a value from the given type instance.
Here's the assembly for
r/1:The interesting part here starts under
{label,2}. The code verifies that the argument is a tuple, then verifies the tuple's arity, and extracts two elements from it. After verifying that the first element of the tuple is equal to the atomfoo, it returns the value of the second element, which is record fieldf.Now let's look at the assembly of the
m/1function:This code verifies that the argument is a map, then extracts the value associated with map key
f.The costs of each function come down to the costs of the assembly instructions. The record function has more instructions but it's likely they're less expensive than the instructions in the map function because all the record information is known at compile time. This is especially true as the key count for the map increases, since that means the
get_map_elementscall has to potentially wade through more map data to find what it's looking for.We can write functions to call these accessors numerous times, then time the new functions. Here are two sets of recursive functions that call the accessors
Ntimes:We can call these with
timer:tc/3to check the execution time for each function. Let's call each one ten million times, but do so 50 times and take the average execution time. First, the record function:This means calling the function ten million times took an average of 238ms. Now, the map function:
Calling the map function ten million times averaged 236ms per call. Your mileage will vary of course, as did mine; I observed that running each multiple times sometimes resulted in the record function being faster and sometimes the map function being faster, but neither was ever faster by a large margin. I'd encourage you to do your own measurements, but it seems that there's virtually no performance difference between the two, at least for accessing a single field via pattern matching. As the number of fields increases, though, the difference in performance becomes more apparent: for 10 fields, maps are slower by about 0.5%, and for 50 fields, maps are slower by about 50%. But as I stated up front, I see this as being immaterial, since if you're trying to use records and maps interchangeably you're doing it wrong.
8xiog9wr2#
使用Erlang/OTP 22 [Erts-10.6]重复测试时，我得到了不同的结果。
r/1的反汇编代码不同：
记录查找速度提高了1.5倍以上。
dnph8jn43#
我将10个元素的记录与同样大小的Map进行了比较。在这种情况下，记录被证明快了2倍多。