|
Atreides_096 Wanderer
Joined: 21 Jan 2005 Posts: 99 Location: Solvang, CA
|
Posted: Fri Feb 17, 2006 11:39 am
Zmud Lag Reduction (trigger overload) |
I've been trying to reduce the lag in my zmud from having too many triggers... the best way I've found is to keep most of them disabled :P However, even with 90% disabled I still get significantly more lag then with all disabled.
I have 2 questions:
1) Would converting my triggers to perl make any real difference?
2) The VAST majority of my triggers are subs. Each one shows a different output, so needs a seperate trigger. I was wondering though... would I get a speed increase if I called them from a zmud database instead? For example, rather than:
Code: |
#ac {Mob1 is here} {#sub Mob1}
#ac {Mob2 is here} {#sub Mob2} |
30 of those triggers... what if I did something like:
Code: |
#ac {{@Area1Subs} {#exe %db(@Area1DB, %1)} |
Would this cause more lag or less? I have about 2200 subs, so to convert enough of them to run a viable taste would take a *long* time :P I am guessng this would actally make it slower rather than faster.. but even with the character limit within dbs I could probably reduce my 2200 triggers into say 220... but the question is, would those 220 triggers still be running 2200 routines as it searched through the variable list? |
|
|
|
Iceclaw Apprentice
Joined: 11 Sep 2005 Posts: 124
|
Posted: Fri Feb 17, 2006 2:36 pm |
I'd like to know the answer because I did a mob db for my mud, but i cant get it to parse all of the descriptions even just in a ZONE fast enough.
|
|
|
|
Vitae Enchanter
Joined: 17 Jun 2005 Posts: 673 Location: New York
|
Posted: Fri Feb 17, 2006 3:21 pm |
Atre,
My suggestion would be use notepad to do a find/replace of like 200 of the #subs
open a fresh char (ya know, esc on the char select screen)
press ctrl-q, gaze at the statbar for ages as it runs, write down the # that shows.
run it a few times and get an avg.
Put in your script.
run the crt-q thing the same # of times.
Compare avgs.
200 is way short of 2200, but multiply the diff by 110?..*shrug*
yeah, i know, not the ideal way to test it, but it's all i got :-)
i'll be happy to convert and test them for ya *drool*
EDIT:
K, since you were AFK on Aard and on AIM, figured i'd run a test myself.
#VAR Area1Subs {mob1|mob2|mob3|mob4|........||mob2098|mob2099|mob2100}
#TRIGGER {^(*) is here.} {#IF (%ismember( %1, @Area1Subs)) {#sub "%1"}} "" {disable}
#echo mob1 is here.
mob1
Before I put in that stuff I crtl-q'd 5 times.
Crappy computer. P3-300 with 300+megs of ram.
avg Time: 19.1
AFTER I put in that stuff
Avg Time: 22.3
I know that that time isn't in seconds, and damned if i know what it is, but with a blank template and just the one trigger thats what I get.
Of course this is prolly not even CLOSE to what you were talking about, but by now ya know me, dunno what the hell i'm doing even when i'm doing it right. |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Sat Feb 18, 2006 6:31 am |
Some actual code would be nice, but from your mock up examples I think you need only 1 trigger.
#TRIGGER {*( is here)$} {#PSUB {} %x1} |
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Atreides_096 Wanderer
Joined: 21 Jan 2005 Posts: 99 Location: Solvang, CA
|
Posted: Sat Feb 18, 2006 8:45 am |
Code: |
#TRIGGER {A animal that resembles both Dragon and Lion leaps from the shadows.} {#sub {A Dragonne is here.}}
#TRIGGER {A beast with the heads of a Gorgon, Lion and Dragon unleashes its petrifying stare.} {#sub {A Gorgimera is here.}}
#TRIGGER {A gray creature leaps at your throat.} {#sub {A Gnasher is here.}}
#TRIGGER {A winged dog-like beast flies toward your neck.} {#sub {A winged gnasher is here.}} |
That's the gist of them anyway ;)
BTW Note the #sub rather than #psub.. the main idea here is to reduce spam and be able to pick out mobs quickly.. most of the other subs are much more detailed, but for code purposes, same type of code and these are easier to read |
|
|
|
Vijilante SubAdmin
Joined: 18 Nov 2001 Posts: 5182
|
Posted: Sat Feb 18, 2006 6:24 pm |
If you use the mapper I would suggest linking the triggers in zone groupings to automatically turn them on and off by zone. Obviously the fewer triggers going the less work there is. It has been shown that using a record variable does not provide an actual speed increase over seperate triggers, in fact it will quite often end up slower due to the further script processing required to produce the substitution text.
The first things I would suggest to improve speed is adjust the trigger options for all the triggers to include "case". By making them cae specific you will cut the amount of processing required during testing them. Next is the "notrig" option; if you do not have further triggers looking to preform scripted actions based on the substituted text then this option should be used.
A final method to gain some more speed would be through tweaking the trigger priorities. This is a slightly complex process, but would allow that once one of the triggers is matched you can turn off all the rest, then by turning them back on with a much later trigger they will never be checked. I am not too sure this really works in zMud, since it is quite difficult to test. However it will definitely be a viable option in CMud, and will be easier to implement there as well. So you may want to keep that in mind during and steps you take in your current design. |
|
_________________ The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
|
|