[erlang-questions] clarify: why bit syntax so slow + benchmark code

Thomas Lindgren thomasl_erlang@REDACTED
Sat Nov 17 10:53:26 CET 2007

--- Mateusz Berezecki <mateuszb@REDACTED> wrote:

> On Nov 16, 2007, at 4:09 PM, Per Gustafsson wrote:
> >>
> >
> > It is slow because for each iteration a two
> sub-binary structure  
> > (about 5 words) is allocated. This will be
> optimized in the next  
> > release of Erlang/OTP, but your code is sub
> optimal anyway, if you  
> > want good performance you should write:
> >
> > test1(<<>>) -> done;
> > test1(<<_A, Rest/binary>>) ->
> >       test1(Rest).
> >
> > That is, you should not first pattern match and
> create a sub-binary  
> > and then match against that one.
> It was written that way to show that some
> calculations are done on that
> matched value later. 

Well, you did ask why the sample code was slow. If
your calculation is big enough, it won't matter.
Otherwise, use Per's reasoning as inspiration for your
future code.

> Generally speaking
> I'm having a trouble parsing a stream of data
> where each control frame is single byte and I have
> no knowledge of
> the stream unless I parse that single byte (i.e. and
> ~3-4 bytes after  
> it - they vary depending
> on that first single byte).

One scheme to extract such data is this:

-define(ARG1, 36).

f(<<?ARG1, Arg, Rest/binary>>) -> ...;
f(<<?ARG2, Arg1, Arg2, Rest/binary>>) -> ...;
f(<<?ARG3, Arg1, Arg2, Arg3, Rest/binary>>) -> ...;
f(<<?ARG2_short, Arg1, Arg2:16, Rest/binary>>) -> ...;
f(<<?ARG_u32, Arg:32/unsigned, Rest/binary>>) -> ...;

and so on. In R11, this method is suboptimal since it
still builds Rest in every iteration, but that should
improve in R12.

> I'm curious, can erlang achieve good performance
> with that kind of stream data filtering?

Since we just had a long discussion on the topic, why
not have a look at the widefinder mail threads from a
couple of weeks back? The mailing list archives can be
found at erlang.org.


Get easy, one-click access to your favorites. 
Make Yahoo! your homepage.

More information about the erlang-questions mailing list