Re: multibyte strings & bucket-of-bytes efficiency under 1.9.0

On 03/01/2008, Rick DeNatale <[e-mail]> wrote:
> On Jan 3, 2008 10:40 AM,  <[e-mail]> wrote:
> >
> > The main selling point of being able to use a regex on a bucket of bytes
> > is that, from a Ruby 1.8 perspective, it's too damn slow to search through
> > them and manipulate them any other way.
> >
> > From my perspective, the things that I want to be able to do are to look
> > for particular sequences of bytes, and to read or remove ranges of bytes
> > from the bucket.
> >
> > If a ByteArray, however it is implemented, can give me the ability to find
> > things in it quickly, without resorting to a regex, then that's great.
> > If it can not, though, then they are not particularly useful without some
> > other way (like regexps) of doing so.
>
> Things like fast searching for a sub-bytearray could easily be
> implemented, as well as slicing etc.
>
> If you really need generalized regexp searching they might not be the
> best solution.
>
Well, in 1.8 the generalized regexp solution was the fastest way. And
unless we want to redesign most of the code that deals with byte
buffers we should allow it to be used in the future. You do not really
need a regexp to search for "GIF" or the MIME separator, a substring
is sufficient. But regexps are what was available, and it should
continue to be.

As far as I understand, the operations that were slow were things like
slicing and concatenation that do not depend on regexps at all.

Perhaps the strings could be more optimized by making the different
encodings separate. That is the force_encoding method would return a
new string with possibly different internal representation and method
implementation in place. Since you would not be able to change the
encoding of the string the methods would always match the data
representation.

Thanks

Michal