[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Triggers speed
Triggers speed

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Posted by Ovvi   Poland  (13 posts)  [Biography] bio
Date Mon 25 Apr 2005 05:39 PM (UTC)
Message
I want to add a few hundreds triggers from a script. All triggers will be similar, and I am not sure what will be faster work -> one trigger with all inside or many triggers?
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #1 on Mon 25 Apr 2005 07:36 PM (UTC)
Message
It would depend on how similar they are. I would imagine one trigger would be fastest. But it really does depend on how similar the triggers are (and what you're doing with them after you match).
But either way, triggers are awfully quick.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Ovvi   Poland  (13 posts)  [Biography] bio
Date Reply #2 on Tue 26 Apr 2005 08:47 AM (UTC)
Message
for example:
one trigger: (troll|goblin|dwarf|...)
or
every world in single trigger

What will be faster work?
[Go to top] top
Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #3 on Tue 26 Apr 2005 09:56 AM (UTC)
Message
Putting them all in one trigger will be faster. For both evaluating, and keeping up to date (and editing later down the road).
Not only that, but you'll be able to keep your sanity.

Even if it wasn't faster, triggers take such a small amount of time to evaluate (unless you're doing something wrong with scripting), that it wouldn't be worth the effort to create all the different ones.

There are lots of secondary benefits (smaller world file, and the benefits that branch off of that) that also weigh in on the side of fewer triggers.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
[Go to top] top
Posted by Kiana   (3 posts)  [Biography] bio
Date Reply #4 on Fri 04 Nov 2005 11:02 PM (UTC)
Message
I have a trigger that will work on probably 140 tables. My question is: is it faster if I write 140 seperate triggers or should I keep it as one trigger?
(Actually my trigger is working base on which table is affected by customer transactions and there is 140 if-else for table names)
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Sat 05 Nov 2005 04:39 AM (UTC)
Message
Probably one trigger, because of the trigger set-up time etc.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Wink   (16 posts)  [Biography] bio
Date Reply #6 on Fri 25 Nov 2005 12:40 AM (UTC)

Amended on Fri 25 Nov 2005 12:41 AM (UTC) by Wink

Message
I'm curious, at what point does combining all the triggers into one not become faster? I'm wondering because I've got a large number of triggers that I can do this with that pretty much vary only in whether they have a ^ at the beginning or not.

Would something like (?:give a fearsome roar\.|^You wink knowingly\.$|You close your eyes|^A shimmering image) be a fine trigger to use speed-wise, or would I be best off keeping them all separate?
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Fri 25 Nov 2005 05:09 AM (UTC)
Message
This is an interesting question. It is hard to say for sure on things like whether or not the trigger has a ^ a the start - although you could test it like I have done below.

My first point is that if there is something that is much more likely to match than other things (eg. the prompt line) then it will be quicker to put that as a separate trigger, with a lower sequence number. That way, if this line arrives, the trigger matches and the other ones don't have to be tested.

To check out which is faster - one trigger with many match paths, or lots of individual triggers, I wrote a small test routine that generated 1000 random match strings, and either generated 1000 triggers, or 1 trigger with 1000 alternate matches inside it.

This is the code:



function gentriggers ()

MtSrand (1) -- seed generator

-- method 1 - different triggers

--[[
for i = 1, 1000 do
  match = utils.tohex (utils.md5 (tostring (MtRand ())))
  AddTrigger("", match, 
       "", trigger_flag.Enabled , custom_colour.Custom2, 0, "", "")
end -- for

--]]

-- method 2 - one big trigger

regexp = "^("

for i = 1, 1000 do
  if i ~= 1 then
    regexp = regexp .. "|"
  end -- if not first one  
  match = utils.tohex (utils.md5 (tostring (MtRand ())))
  regexp = regexp .. match
end -- for

regexp = regexp .. ")$"

AddTrigger("", regexp, 
     "", trigger_flag.Enabled + trigger_flag.RegularExpression, 
     custom_colour.Custom2, 0, "", "")

end -- function


I initially used method 1 - 1000 triggers, then commented it out (as above) and tried method 2.

I let this generate the triggers for me, saved the world file, and then reconnected, and used the "info" window to see how much time had been spent on evaluating triggers (Shift+Ctrl+I).

These are the results:


  • 1000 triggers - 0.29351 seconds

  • 1 (big) trigger - 0.008946 seconds


It seems that one big trigger is 32 times as fast, so that should give you something concrete to decide on.

My test data was 324 lines received from the MUD, the connection data then the "help" information 10 times. Even using the slower method, it is matching 1000 triggers in under 1/1000 a second per line, so it is still pretty fast.

Since the triggers were just random data, then none matched, which is the worst-case scenario, as the incoming line has to be tested against all possibilities.

The trigger match text for the 1 trigger was:


^(8737703909D6F2E145E44444486B5205| ... (and so on) ... |754B497A32D72393529A99E36CE150FD|2304849F548D74B1F1B6336BBEFF9729)$


The triggers generated individually were:


<triggers>
  <trigger
   custom_colour="2"
   enabled="y"
   match="0029AA3F2BDAD35EE63281B77CD3FA98"
   sequence="100"
  >
  </trigger>
</triggers>

(and another 999 like it)


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Wink   (16 posts)  [Biography] bio
Date Reply #8 on Sun 27 Nov 2005 02:01 AM (UTC)
Message
Interesting results, Nick, and thanks for the information. I decided to begin combining the triggers into one, keeping in mind what you mentioned about very common lines, such as the prompt. I'm unsure if I'll notice any difference in speed, based on the one thousand individual triggers you used still processing quickly, but it will reduce the effort needed when I need to make changes.
[Go to top] top
Posted by Kiana   (3 posts)  [Biography] bio
Date Reply #9 on Wed 30 Nov 2005 01:09 AM (UTC)
Message
I still have a question: My trigger is supposed to fire when any inserts, updates or deletes occure in our large and very busy database. My plan is to make a mirror table for each table and reflect any changes by firing triggers on them. (some thing look like replication) . Now do you guys still think that is it a good idea to use one big trigger for whole database and have a probably 140 condition statement for each table name , instead of having 1 trigger for each table? Does it make the database slow?
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #10 on Thu 01 Dec 2005 11:18 AM (UTC)
Message
Quote:

My trigger is supposed to fire when any inserts, updates or deletes occure in our large and very busy database. My plan is to make a mirror table for each table and reflect any changes by firing triggers on them. (some thing look like replication) .


I don't understand this bit. MUSHclient is a MUD game client program, not a database replication system. It is not designed or intended to be used for that purpose.

Quote:

Now do you guys still think that is it a good idea to use one big trigger for whole database and have a probably 140 condition statement for each table name , instead of having 1 trigger for each table? Does it make the database slow?


I have already done the test shown above that seems to indicate, for my test data which I have shown you how to reproduce, that for 1000 triggers one big trigger is over 30 times as fast. Does that not answer your question?

My suggestion is, for anyone who wants to know if Method A or Method B is faster, to write a test script that does both methods and times them, like I did.

However I repeat that MUSHclient is not intended to be used for some sort of bizarre database replication strategy. I am having some trouble even imagining how it might be used in that way.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Kiana   (3 posts)  [Biography] bio
Date Reply #11 on Fri 02 Dec 2005 09:20 PM (UTC)
Message
Thanks for your reply.
What you did is 1000 trigger without any conditions ,but in my case, it is different. It needs to check the condtions before firing any triggers, although all the triggres are the same but it needs to know which table should fire the triggre.
Actually what I need right now is to find out a way to simulate 1000 users or more that are working with our databse at the same time and run the system and measure the time in both cases (with having these triggers and without triggers) and show to our Network adminstrator that my trigger is not going to bring the speed of the databse as much as he think down!
Do you have any idea of how can I do that?
Is there any softeware that can simulate diffrerent conditions on server and see the results?
Any idea?

[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #12 on Fri 02 Dec 2005 11:04 PM (UTC)
Message
Once again you have lost me. You need to test a condition before firing the triggers, but "all the triggres are the same"?

Unless you can demonstrate in what way this problem is related to playing MUD games, I am going to have to suggest that you make enquiries at a "code guru" or similar site.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

28,258 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]