[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: struct.el -- a package to encode/decode binary data

From: Stefan Monnier
Subject: Re: struct.el -- a package to encode/decode binary data
Date: Thu, 21 Mar 2002 11:53:59 -0500

> On the surface, it looks "obvious" to use unibyte strings for
> data which is known to be - and processed as - byte-oriented
> data.

Agreed.  Unibyte strings are basically byte-arrays whereas
multibyte-strings are char arrays.  In your case you're dealing
with bytes rather than with chars so it makes more sense (to me)
to use unibyte strings.

> >                                            IMO, unibyte strings
> > should not be used unless absolutely necessary, ideally never.
> Am I right in assuming that aref, aset, and substring are potentially
> much slower on a multibyte string than on a unibyte string?  Probably
> not noticeable if you just look at a single char from a string, but
> what if you loop over a string (forwards or backwards)?

I think it's worse than that.  `aset' on a multibyte string is very
difficult to support in the case where you replace a char with another
of a different byte-length: it ends up allocating a whole new string.
This is really bad.  I think `aset' on strings should simply be disallowed
(I have it disabled here).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]