chicken-users
[Top][All Lists]
Advanced

[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.





reply via email to

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