[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] using mmap files as strings?
From: |
F. Wittenberger |
Subject: |
Re: [Chicken-users] using mmap files as strings? |
Date: |
Wed, 03 Nov 2010 12:36:18 +0100 |
Am Dienstag, den 02.11.2010, 22:17 +0000 schrieb Alaric Snell-Pym:
> On 11/02/10 14:53, Felix wrote:
> > From: Alaric Snell-Pym<address@hidden>
> > Subject: Re: [Chicken-users] using mmap files as strings?
> > Date: Tue, 02 Nov 2010 13:22:01 +0000
> >
> >> Then have blobs, strings, srfi-4 vectors, and friends all have the
> >> option of being a reference to one of the above with an offset and
> >> limit, so they can be views into arbitrary data from external sources.
> >
> > That's the problem: all primitives on those objects have to check
> > whether they have to handle such a "view" object. Handling these
> > special cases are too costly and prohibit optimizations.
>
> *nod* that's the downside. I've been wondering how to address it.
>
> One way would be to give every blobby object a small header with a data
> pointer and offset in (the rest of it either containing the data, or a
> reference to the real store of the data so it gets noticed by the GC, as
> the raw pointer may be into the middle of it). This would make for a
> double indirection to get to the data in every operation, but that would
> be done just once for bulk operations written in raw C.
I wonder if it would be feasible to to support 'heavy strings' by a
compile time option. At worst this could imply that there would be
2 .so files per egg, one for cheap strings and one for heavy strings.
Sure certain optimizations will be gone. Users will have to try which
one works better for them. I bet those with many CD image sized strings
will be better served with heavy strings while curses based windowing
systems probably better steer clear of them.