Re: [BDW-GC] "Inlined" storage; `scm_take_' functions

2009-09-09 Thread Neil Jerram
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

Re: [BDW-GC] "Inlined" storage; `scm_take_' functions

2009-09-09 Thread Ludovic Courtès
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

Re: [BDW-GC] "Inlined" storage; `scm_take_' functions

2009-09-08 Thread Neil Jerram
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

Re: [BDW-GC] "Inlined" storage; `scm_take_' functions

2009-09-01 Thread Ludovic Courtès
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

Re: [BDW-GC] "Inlined" storage; `scm_take_' functions

2009-08-31 Thread Mike Gran
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

[BDW-GC] "Inlined" storage; `scm_take_' functions

2009-08-31 Thread Ludovic Courtès
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