[erlang-questions] ETS: binary matching in match specifications
Mon Aug 8 02:08:43 CEST 2011
There doesn't seem to be any type of binary data type matching in a match specification besides '==' or '/='. To compare apples to apples and to exclude OS/hardware variances the following test shows the differences in using a 4 segment binary as a key (128bits total) and a 4-tuple of integers as a key. The segments of the binary and the tuple values for the lookups are randomly generated so as to eliminate any type of issue there. The methodologies in the 2 algorithms are exactly the same save the form of the key. Based on this data the speed of binary based lookups are somewhat superior than tuple based lookups. The problem is that we have a need to do certain types of ets matching on the binary keys (3 segments are _ whereas one segment is an int()). The question is this:
Why are there no other ets match conditions than '==' and '/='?
Is it just a development time/complexity issue or is there a more fundamental reason such as reducing the use of match specifications in favor of another approach. Or is it simply convention that this type of problem is best solved using the tuple approach? Our issue is that 99.999% of the time we need the speed of the binary '==' match and the rest of the time we need an incredibly simple match on a portion of the binary. And the memory cost of storing an alternate structure for that small use case is not acceptable. It would be great if even 'band' could operate on a binary type in a match specification.
% Col1 == Number of elements in table
% Col2 == Memory size of table
% Col3 == Average ets:member/sec for 10M lookups
1> test:do_ets_test(). % Using 4 segment 128bit Binary for Key lookup
4, 362, 7369196
19, 557, 6476683
79, 1337, 6476683
319, 4457, 6345177
1279, 16937, 5882352
3> test:do_ets_test(). % Using 4 element tuple of integers for Key lookup
4, 358, 6345177
19, 538, 5773672
79, 1258, 5777007
319, 4138, 5724098
1279, 15658, 5479452
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions