l...@gnu.org (Ludovic Courtès) writes:
> It’s not such a shame IMO because:
>
> * You have to allocate anyway, to store the (double) cell, and
> allocating the whole thing may be just as costly as allocating the
> cell, at least for small stringbufs/bytevectors.
>
> * For stringbufs, t
Hi Neil!
Neil Jerram writes:
> l...@gnu.org (Ludovic Courtès) writes:
>> Stringbufs and bytevectors are now always "inlined" in the BDW-GC
>> branch [0, 1], which means that there's no cell->buffer indirection,
>> which greatly simplifies code (it also takes less room and may slightly
>> improv
l...@gnu.org (Ludovic Courtès) writes:
> Hello!
Hi!
> Stringbufs and bytevectors are now always "inlined" in the BDW-GC
> branch [0, 1], which means that there's no cell->buffer indirection,
> which greatly simplifies code (it also takes less room and may slightly
> improve performance).
>
> The
Hi,
Mike Gran writes:
> On Tue, 2009-09-01 at 02:14 +0200, Ludovic Courtès wrote:
[...]
>> The `scm_take_' functions for strings/symbols/bytevectors are now
>> essentially aliases to the corresponding `scm_from_' because we cannot
>> advantageously reuse the provided storage.
>>
>> Should the
On Tue, 2009-09-01 at 02:14 +0200, Ludovic Courtès wrote:
> Hello!
>
> Stringbufs and bytevectors are now always "inlined" in the BDW-GC
> branch [0, 1], which means that there's no cell->buffer indirection,
> which greatly simplifies code (it also takes less room and may slightly
> improve perfor
Hello!
Stringbufs and bytevectors are now always "inlined" in the BDW-GC
branch [0, 1], which means that there's no cell->buffer indirection,
which greatly simplifies code (it also takes less room and may slightly
improve performance).
The `scm_take_' functions for strings/symbols/bytevectors are