On Wednesday, June 4, 2014 2:55:26 PM UTC+2, Ivar Nesje wrote:
> I think push!() is faster because the other option is accessing an array
> that contains `#undef` values (Julia speak for a NULL pointer) and this is
> slower than accessing a regular array that does not contain #undef.
>
> See:
>
> http://docs.julialang.org/en/latest/manual/faq/#nothingness-and-missing-values
>
Yes, I've seen that. Strikes me as odd that assignment should be affected
(especially more than appending), but you may very well be right.
> I would guess that you should rather worry about the overhead of boxing
> and garbage collecting the elements of the array. The Array{Any} only
> stores pointer, but the boxed values they point to is much bigger. For
> performance you should probably consider using a concrete array that stores
> values instead of pointers to values (not abstract element type).
>
As I said, the numbers are just filler. I have a bunch of objects that are
neither allocated nor deallocated during a run of my algorithm. The array
in question is used to do constant-time initialization, using the standard,
folklore algorithm, but rather than two arrays, I have this array and an
index stored in each object. The objects can be of different types, and the
only job of this array is to store the identity of each of them at a given
index, so I can check (using ===) whether they have been initialized.
So, with that extra clarification out of the way, my question remains … how
do I best implement an array that grows and is periodically reset to zero?
Should I just use push!() and resize(…, 0), or is there some better way?
I'm also open to other suggestions on doing this. Would it help if I used
an abstract superclass for my objects? (I doubt that could affect anything;
you'd still have to store pointers.) Or if I explicitly used Ptr{…}
objects? Or simply stored object IDs as unsigned ints, perhaps, somewhat
like in ObjectIdDict?
Or maybe I should forget about it, and just traverse my datastructure
between each run, and have a linear reset rather than a constant one. Would
probably be fast enough – and would avoid premature (and possibly
counterproductive) optimization ;-)
