bstring.erl in the next release?

[Sean Hinde]

Hi,

> jmarant@REDACTED (=?iso-8859-1?q?J=E9r=F4me?= Marant) writes:
> >
> >Hi,
> >
> >  I was seeking for a binary implementation of string functions
> >  and someone gracefully pointed me to the mail archive at
> > 
> >  
> http://www.erlang.org/ml-archive/erlang-> questions/200103/msg00134.html
> >
> >  What about integrating this module in the next Erlang 
> release? (unless
> >  it is already there).
> 
> However, as the string library is mainly about pulling apart strings
> then a bstring library would probably be in place.  A bregexp as well
> would be nice.
> 
> Sean, have you tested the efficiency of your drivers against using
> bit-syntax directly?

Yes, I did some quick tests.

Some quick and dirty results (figures given are averages over quite a number
of runs):

L = lists:seq(1,255).
B = list_to_binary(L).

1> timer:tc(string, chr, [L, 255]).
{76, 255}
2> timer:tc(bstring, chr, [B, 255]). % Driver
{40, 255}
3> timer:tc(bstring, chr2, [B, 255]). % Bitsyntax linear search
{260, 255}

The current bitsyntax doesn't appear to do that well if parsing byte by
byte. 

We have found it to be much quicker than list crunching for our protocol
decode functions though. e.g Splitting 100 octets into 10 groups of 10
octets is much quicker with bitsyntax than parsing every byte through a
list.

bifs for bstring:chr, str, rchr, rstr, and perhaps reverse would be one way
to redress the balance.

Some addition to the bitsyntax a la the original would be even better:

1> <<_:Pos/binary, 4, Tail/binary>> = <<1,1,1,1,1,1,1,1,1,4>>.
<<1,1,1,1,1,1,1,1,1,4>>
2> Pos.
10

Rgds,
Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.