Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Sun Dec 17, 2006 1:48 am   

local variable questions
 
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.
Reply with quote
Ceres
Wanderer


Joined: 25 May 2006
Posts: 88

PostPosted: Sun Dec 17, 2006 2:54 am   
 
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.
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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 :)
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
crycry
Apprentice


Joined: 24 Jun 2006
Posts: 169
Location: UK - South Coast

PostPosted: 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.
_________________
'Life is what happens, when your too busy doing something else'

_________________

XP Pro SP2
cMud 1.24
_________________
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Mon Dec 18, 2006 4:54 pm   
 
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.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Mon Dec 18, 2006 5:37 pm   
 
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
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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)}
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Wed Dec 20, 2006 6:33 pm   
 
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.
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Wed Dec 20, 2006 11:06 pm   
 
Arminas wrote:
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.

I knew Zugg was planning to work on functions, but I hadn't checked the version history to see if he already had. I was kinda hoping that maybe "local functions" was his answer to the problem.

The new system I am writing is going to depend heavily on functions to make it simple for people other than myself to use. So.. I guess I'll hold off on writing it, as you said.

@Zugg: Will the syntax for functions (#FUNC) change.. i.e. can I write it all now and expect them to still work after the new function changes are done? Or at least be close enough that its not a major headache to 'fix' them?

@Arminas: The third syntax works, its how I do that currently. The first -should- work, but I never really 'got into' using the shorthand syntax for database vars. It kind of confuses me to look at, so I stick to %db.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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}}
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net