[DGD] Clones and very large arrays

[Bart van Leeuwen]

On Sat, 3 Apr 2004, Robert Forshaw wrote:

> >From: Bart van Leeuwen <bart at wotf.org>
> >Hmm, you obviously never had 'rogue' clones out there, ie, somethign ended
> >up making a zilion clones of an object due to some bug..
>
> Perhaps that's why lightweight objects were mentioned...
>
> >
> >Basicly, when you run a persistent mud, keepign track of which objects are
> >loaded, and which clones they have is the only possible way to not end up
> >with lots and lots of junk that will never be needed again, or at least
> >gives you a way to find and remove such junk.
> >
> >Then, it is quite nice to be able to do something like
> >query_clones(obj)->function(args);
>
> Hmm! That looks like you're trying to call a function in an array. ; ) But I
> know what you mean.

Ah yes.. that is indeed what I do. Forgot that calling a function in an
array like that is one of my mods to the kernel (its somethign I really
like, even if it is 'syntactic sugar' and could be replaced by a
call_array like construct)

>
> > > I didn't understand that, the example you gave is rather ambigious and
> >seems
> > > to be suggesting that I store an array of clones referenced by a clone!
> > > Surely I want it referenced by a master?
> >
> >The basic issue is this:
> >You store an array of 20000 clones in the master, which means that when
> >the master gets swapped out, DGD has to swap out that entire array as
> >well.
>
> Sounds like quite a significant performance problem. However, storing the
> array in an object daemon as so:
>
> clone[a_master_object] = ({ some_clones })
>
> Eliminates this swapping problem, doesn't it? And this is how I was doing it
> to begin with! That just leaves me with the array size issue. I'd still like
> to hear whether the idea of making arrays of clones within arrays would
> solve this problem (or even make matters worse), since I've never seen that
> done or seen it suggested before. It would certainly prevent the array size
> limit from being hit as easily (32767 x 32767 = 1073676289), that's a few
> billion or so.

Well, it moves the problem to the object daemon... what if that one gets
swapped out? ;)

I suggested arrays of arrays of clones a while back, and I have some
experience with it. Search the archives for the 2nd half of 2003 for the
discussion, some interesting points were made for the different solutions.

>
>
> >That said.. in ancient lpmuds, such a linked list was used for example for
> >keeping track of pieces of equipment that a player was 'wearing'.
>
> The good old days sucked did they not? : )
>
> >This
> >solution caused many bugs due to chains being broken and replacing it by
> >an array or mapping (in the player object) makes quite a difference in
> >reliability.
> >
> >Basicly, the problem with chains is that they have a tendency to break and
> >that you are kinda lost when they do.
>
> Chain breakage should never happen though if you implement the linked list
> properly?

Well, if you have a reliable destructor in LPC, then you can do that.

>
> >
> >That is why I am using arrays instead of a linked list (besides the fact
> >that an array allows me to call a function in all clones easily)
> >
> >Trying to increase max array size to sizeof(long)/2 doesn't sound like a
> >good plan to me however.. I am not sure (and Felix pls correct me if I am
> >wrong) but it might well be that there are places where an array might be
> >indexed using an int instead of a long. Makign the max size bigger then
> >32767 might result in some subtle and interesting bugs due to that.
>
> I'd like to hear from Felix whether it is possible then. I imagine though
> that even if it were possible, super-big arrays would create a performance
> hit when trying to manipulate it, like in my previous example, deleting an
> element containing particular data.
>

Could well be.. I never noticed a real performance hit of increasing the
max array size from 1024 to 32767 (in the lib/kernel) but I have no
experience with making it bigger.

Bart.

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd