> - 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
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):
> - 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
> - 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.