You can take a pointer to an array and reinterpret it as a smaller array, which sounds like (sort of) what you want.
https://gist.github.com/anonymous/e8042c8bffe49c3aa886 (whether this is more performant and/or a good idea is left as an exercise :) On Wed, Jun 4, 2014 at 10:22 AM, Magnus Lie Hetland <[email protected]> wrote: > 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 ;-) >
