bstring.erl in the next release?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

bstring.erl in the next release?

Jérôme Marant

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).

  Cheers,

--
J?r?me Marant <jerome.marant>
              <jerome>


Reply | Threaded
Open this post in threaded view
|

bstring.erl in the next release?

Robert Virding-4
jmarant (=?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).

While using binaries for strings is sometimes a big win you have to be
careful.  The problem is that while the representation is more compact
and scanning can be quite efficient, either using a driver as Sean
Hinde or the bit-syntax directly, building binary strings incremently
can become quite costly.  Much more costly than using lists.  Also
binaries are like all other Erlang objects in that they canot be
modified, only created.

This problem when creating binaries, even with the bit-syntax, is a
general problem with binaries not just when using them as strings.  I
recall there has already been a discussion about this.

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?

        Robert


Reply | Threaded
Open this post in threaded view
|

bstring.erl in the next release?

Jérôme Marant-2
Robert Virding <rv> writes:


> While using binaries for strings is sometimes a big win you have to be
> careful.  The problem is that while the representation is more compact
> and scanning can be quite efficient, either using a driver as Sean
> Hinde or the bit-syntax directly, building binary strings incremently
> can become quite costly.  Much more costly than using lists.  Also
> binaries are like all other Erlang objects in that they canot be
> modified, only created.
>
> This problem when creating binaries, even with the bit-syntax, is a
> general problem with binaries not just when using them as strings.  I
> recall there has already been a discussion about this.
>
> 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.

  Once again, the most efficient solution would be to handle strings
  as binaries internaly avoiding the use of extra layers such as a
  bstring library or driver. Any time to have to communicate with
  other applications via some Internet protocol, you have to convert
  strings to binaries and that could be avoided.

  Hence, I woud see:
  - strings implemented as binaries within the interpreter
  - a lstring library in order to manipulate strings as lists

  Cheers,

--
J?r?me Marant <jerome.marant>
              <jerome>