Re: [Ocaml-lib-devel] Dynarray (good one)

[Nicolas C. <war...@fr...>]

> - I don't think we're losing much (if anything) to using for loops instead
> of array blits.  We're moving whole words which are word aligned by
> definition, which is generally fast in general.  Memory bandwidth
> dominates.  I just used the array functions because I could.

If you look at the array.ml sources, you'll see that blit is actually doing
a for loop :-)

> - Are floats unboxed or boxed?  I thought boxed.  Note: in this case boxed

Sorry , I messed up when posting the mail : <<< floats ARE boxed >>>

[..]
> Meanwhile, with boxed floats, it would take 2*n + n*4/3 or 10/3 words per
> float, meaning the boxed version is only 25% more memory usage than the
> unboxed version.
[...]

Agree with you.

> - the problem of the array being mutated behind enum's back is a general
> problem with imperitive programming.  It's known as a "bug".  Note that my
> implementation may have had other problems, I didn't think about the
> enumerations that much.  I'd say leave the problem children out for now,
> and if there's demand for them later, we'll add them then.  Fight feeping
> creaturitist!

If I can't feel asleep one of theses nights, I will surely add them and
eventualy catch headache :)

> - Is there a reason you split off conservative_exponential_resizer from
> the normal exponential_resizer?  I didn't think the extra couple of

What do you mean here ?

> branchs were that bad, especially considering that normally you don't even
> reach them, and of the times you do you are hard limited to O(log N)
> iterations of either loop.  Especially considering you are calling resizer
> less often.  The default definately should be the conservative one.
> Correctness over small gains in speed.

I agree for conservative as default.

> - delete has a bug if you're not deleting the last element and not
> reallocating the array- the last element doesn't get nulled out.  It
> should be (about line 194):

Thanks, corrected

> - in to_array, can we replace the for loop with just:
>      Array.init d.len (fun i -> iget d.arr i)
> ?  This allocates a closure, which is it's only downside.

This one is only a inlining of the Array.init function.
A little better for speed, because no closure and better compilation since
same module.

> - of_array: do we want to call resizer to see what size to make the
> original array?  For example, if we're using step_resizer, and the array
> length is not a multiple of the step, the next time we do much of anything
> with the array we're reallocating the array.  Also, this means we don't
> have any space initially for inserting.  But this will make of_array more
> complicated, we can't just use idup.

Yes, but since resizes are most of the time amortized , resizing now or
later is not very important.

I also added "compact" that is shrinking the dynarray to it's minimum size.
I will commit the sources on the CVS now.

Nicolas Cannasse