[DGD] Working with parse_string()

Felix A. Croes felix at dworkin.nl
Fri Jul 24 12:12:37 CEST 2009


Kamil N <kamiln at gmail.com> wrote:

>[...]
> Now question to
> Felix - should I worry about the "cost" of such operation, assuming I
> won't allow last parse_string argument to be higher than 5? Servers
> are nowdays quite powerful, much powerful than at the times when DGD
> was first released, so I wonder if I should even worry about
> performance issue at this stage, or I should concentrate on making
> things work without overoptimizing?

It depends on how you look at it.  With a normal command sentence, in
absolue terms you can afford to parse this on even 15 year old hardware.
But if someone manages to type a command with 5000 adjectives, your
parser may suddenly allocate an extra gigabyte of memory.  On the other
hand, since you're effectively using LPC to determine where OBJI ends
and LIV starts anyway, at this point doing that fully in LPC is probably
more efficient.


> After doing some code that had to run through arrays etc. I started
> wondering - why there are no functions like sort_array in DGD and
> similar ones that make data manipulations less painful - I tried to
> find info about this on lists but couldnt find anything. Should I
> write these functions myself? If so, where to add them? I read that I
> shouldnt put everything in AUTO object because any change there means
> recompiling every single object that exists on the mud. I must admit
> it feels a bit strange not to have all the functions I knew from other
> LpMuds, does it mean its ok to add them myself, and where its best to
> do it? I always throught all "low level" functions like those used to
> manipulate basic data types should be coded in the driver because of C
> speed and stuff like that :) Does it mean DGD is so quick I can as
> well code them in LPC and it will be fine, even with functions that
> are going to be used very often in the code?

Writing sort_array() in C rather than LPC is a big gain if you use
it a lot.  However, in a typical mud the amount of time spent
executing LPC sort_array() is negligible.  Compared to all the other
code in a mud, it is almost never used, so there isn't much point
in rewriting it in C.


>  I also found some weird behaviour I havent noticed before:
>
> 1) allocate(n) was once filling array with zeros, now its nill - are
> there any plans to change it behaviour so for example it fills array
> with empty values of this array's type, for example for string *arr
> its "", for int *arr its 0 etc. Or maybe just adding different
> function doing this?

Like allocate_int() and allocate_float()?

DGD considers nil to be the empty value for all strings, objects,
arrays and mappings.


> 2) I tried to find kfun m_delete, but only found that I should set
> value of given mapping key to 0 to remove it - it doesn't seem clear
> to me, what happens if I want to actually store this information:
> mapp[key] =3D 0 instead of removing key element completly? Having
> mapping value set to 0 and not having that element at all are not the
> same things in my eyes :) Maybe I just got it wrong, will be grateful
> if someone can clear this for me :)

To delete a mapping element, you set it to nil.  With a typechecking
mode less than 2 (in DGD's configuration file), nil and 0 are the same
thing.

Regards,
Felix Croes



More information about the DGD mailing list