On Monday 25 July 2005 01:32, skaller wrote:
> On Sun, 2005-07-24 at 16:23 -0700, Stephane Glondu wrote:
> > On Sunday 24 July 2005 14:55, skaller wrote:
> > > If you have to initialise the store, it is expensive,
> >
> > I understand your point now. However, if you want your array to hold
> > allocated values, you will always have to initialise the array.
>
> Not if the collector is modified by INRIA to support variable
> length arrays: this is some kind of tagged block with
> a mutable length count which limits how far along the block
> the collector looks for boxes: the length count is less
> than or equal to the actual number of allocated slots.

As I recall, the last time we discussed this, Damien said that altering the 
run-time to allow variable-length arrays would slow the run-time down for all 
other code and would be likely to introduce bugs.

I came from a C++/STL background and was accustomed to using extensible 
arrays. Having tweaking my perception of suitable data structures to be more 
appropriate when coding in OCaml, I now prefer the idea of a faster run-time 
and no extensible arrays. I've never actually needed them (except inside 
Hashtbl).

> > Moreover,
> > I think the overhead of this initialisation is insignificant compared to
> > the GC overhead.
>
> I am not so sure: to initialise an array causes a store
> in each slot, which forces the whole array to scroll
> through your cache: if the array is big this means
> disk paging/swapping activity.

You could RLE the uninitialised elements to recover memmap capability.

> ...
> However that turned what in C is a trivial set of
> library functions into a complex unreliable mess
> and left me wondering whether the encoding was
> properly transparent.

I'd just go for the simplest approach, at least to start with.

> > I didn't mean to change the dummy value all the time! Just take the first
> > value as the dummy value, and keep it even if the first entry in the
> > array changes. This will work fine for small values.
>
> But if you do that you have a reference to an object
> that the client does not know about. So the client
> will be confused if the object isn't finalised,
> and that in turn could cause many other objects
> to remain alive unexpectedly.

How can that be a problem given that you (basically) cannot guarantee 
collection anyway?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Technical Presentation Software
http://www.ffconsultancy.com/products/presenta