[erlang-questions] clarify: why bit syntax so slow + benchmark code
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
> 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:
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