Zugg Software :: View topic

Posted: Sun Dec 17, 2006 1:48 am

Lets say I have a whole bunch of triggers and aliases that control the values of four stringlists, tracking afflictions that I have.

#AL stupidity {#addi herbaffs 005_stupidity}
#TR {Hmm. You feel suddenly stupid.} {stupidity}
etc.

Obviously I need to use normal variables for this, since there are multiple scripts involved and the value of a local variable would not be preserved.

But..

#AL cureaff {
bunches of ifs
some more ifs
#IF (@cherbb && @herbb && %ismember(@herbaffs)) {%sort(@herbaffs,1);#EXEC %item(@herbaffs,1)}
repeated for salveaffs, pipeaffs etc
}

Would it be a good idea to do the following instead:

$herbaffs={@herbaffs}
$salveaffs={@salveaffs}
$pipeaffs={@pipeaffs}
$entanglement={@entanglement}

at the beginning of the alias, then from there on refer only to the local variable versions?

At the moment, in zmud, that alias takes about 120ms to parse. I've had to do quite a few things to my overall system to make sure it doesn't get called too quickly, and anything I can do to speed this up, I am interested in.

The file on local vars is non-existent though, so I have no idea when and when not, to use them.

Wanderer Joined: 25 May 2006 Posts: 88

Most definately.. I have a quite complex script which would take roughly 80 ms to process in zMud .. after modifying what I could to local variables in CMUD it now processes in 16 ms, it is especially useful for loops and #FORALL commands.

Posted: Sun Dec 17, 2006 4:47 am

Is it going to be worthwhile in that example though? I mean.. one %ismember, a %sort and a %item is far from complex :)

Posted: Sun Dec 17, 2006 10:01 am

i would always use local variables when you can, apart from being much much cleaner, your going to run into far less problems from package to package should you accidentally end up with 2 vars with the same name.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I am just guessing here but.
You are loading a local variable into memory and preserving it there throughout the script. With the regular variables you have them saved in a database somewhere and they are being referenced each time they are called, loaded/unloaded. If that is the case then unless you are only accessing a regular variable once in a script anyway it is worthwhile to convert to a local variable when they work.

There were still a few cases last time I checked when they did not work. I don't know if Zugg has fixed them yet.

Then if you need to use an altered value of the variable outside the script load it into a regular variable at the end of the script.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

You may even be able to speed things up more by storing the value of expressions in local variables, at least for expressions you evaluate multiple times in your code. If you keep checking for aeon, asleep, etc, store them in local variables once at the beginning.

There are lots of ways to optimize your processing, in zMUD or CMUD. Smile

Posted: Tue Dec 19, 2006 6:59 am

Thanks. Though, I only ever check for things like aeon once per script. I had to write as efficient as possible back when I had an old P1-233 Laughing

and it became a habit.

I'll keep the advice in mind, thanks guys.

Posted: Tue Dec 19, 2006 7:08 am

Woh.. just a thought. Functions. Are stored in variables.

Are local functions a possibility?

A simple, somewhat contrived example (contrived in that creating a function for this is more trouble that its worth).

climbt={head=ph|torso=pt|left arm=pla|right arm=pra|left leg=pll|right leg=prl}
#FUNC plimb {%db( @climbt, %1)}

#TR {Connects to the (*)!} {lasthit=@plimb(%1)}

OR - with a local function

#TR {Connects to the (*)!} {$plimb={@plimb} ; lasthit=$plimb(%1)}

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

They are a possibility but. Frankly I played with functions during beta testing and Zugg was not amused. He is planning on implementing a new function engine soon. He said that using a function for stuff like the above examples was way slower than just doing the same thing like so.

#TR {Connects to the (*)!} {lasthit=@climbt.%1}

Mind you I can't test the syntax, again I am at work. It could be

#TR {Connects to the (*)!} {lasthit=(@climbt.%1)}

or

#TR {Connects to the (*)!} {lasthit=%db(@climbt,%1)}

But I think all of those syntaxes will work, and I KNOW the ones that work are FAR quicker than trying making a function then converting to a local function. And functions are going to change anyway and I wouldn't want you to have to redo all of your work.

Posted: Wed Dec 20, 2006 11:06 pm

Posted: Thu Dec 21, 2006 1:18 am

I'd expect you to at least have to repaste your code into the new functions, since right now they're no different to other variables. I'm not sure about the usefulness of local functions in what you're talking about (ease for other users) since they wouldn't be able to use your local functions in their own scripts, though.

The syntax you were looking for btw Arminas is

#TR {Connects to the (*)!} {lasthit=@{climbt.%1}}

or perhaps

#TR {Connects to the ($limb:*)!} {lasthit=@{climbt.$limb}}

Posted: Wed Jan 17, 2007 9:29 pm

I plan to use the #FUNCTION syntax for creating new function objects in the future. As you mentioned, right now #FUNC actually creates a variable. In the future (no ETA yet) the #FUNC will create an actual "function object" which will be different than variables and optimized differently.

As for "local functions", I doubt it. Local variables are implemented by storing values on the local runtime stack. There really isn't any way to store a temporary function definition on the stack. At least not that I can think of right now.