[erlang-questions] ETS: binary matching in match specifications

Aaron Bawcom abawcom@REDACTED
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.



Thoughts?



% 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...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110807/5895d841/attachment.htm>


More information about the erlang-questions mailing list