Re: [PATCH] Add a mechanism for passing unibyte strings from lisp to modules.

["Brennan Vincent" <brennan@umanwizard.com>]

tomas@tuxteam.de writes:

> On Wed, Jun 26, 2024 at 04:23:46PM +0300, Eli Zaretskii wrote:
>> > Date: Wed, 26 Jun 2024 14:39:30 +0200
>> > Cc: Brennan Vincent <brennan@umanwizard.com>, acorallo@gnu.org,
>> > 	stefankangas@gmail.com, emacs-devel@gnu.org
>> > From:  <tomas@tuxteam.de>
>> > 
>> > 
>> > On Wed, Jun 26, 2024 at 03:26:52PM +0300, Eli Zaretskii wrote:
>> > 
>> > [...]
>> > 
>> > > > I think it would be great if emacs grew a specialized vector-of-bytes type.
>> > > 
>> > > How will it be different from the Lisp vectors we already have?
>> > 
>> > The box around every byte.
>> 
>> What box?  Please tell more, as I don't think I follow.
>
> Maybe I'm all wrong, but AFAIU, a vector can contain arbitrary Lisp
> values. That makes 64bits/8bits plus boxing/unboxing (which is, I
> assume, quick, but nonzero).
>

Yes, this was my reasoning as well.

(setq foo (make-vector 1000000000 #x00))

causes emacs to consume (at least) 8G of RAM, whereas the similar C
code:

#define SZ 1000000000
char *foo = malloc(SZ);
memset(foo, 0, SZ);

only consumes 1G.

> Having a specialized "array of bytes" (as there is one for bools)
> might be beneficial for big arrays, and perhaps avoid big data moving
> operations over the C/LISP fence.
>
> I do understand your reservations, but I do understand the OP's
> wish as well :-)
>
> If at all, a "byte array" would be, of course, cleaner than a
> unibyte string, with all its implicit magic.
>
> Cheers
> -- 
> t