About Us
Products
Purchase
Downloads
Support
Forums
Contact Us
Site
 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 Goto page Previous  1, 2
Jaegord Posted: Wed Dec 19, 2007 1:15 am
Speed, what gives and takes?
Fang Xianfu
GURU


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

PostPosted: Thu Mar 20, 2008 4:14 pm   Re: Anchor triggers
 
leonardofaoro wrote:
Vijilante wrote:
There are a few things you can do to adjust these problems. First cut down the number of trigger you have, if you have 17 different triggers that all do the exact same thing use a list pattern and a list variable and achor it at the start of the line. The matching engine actually compares against all 17 things at once when it is anchored, and as it eliminates one from being possible it stops checking that one. The reason for the third thing I mentioned is a bit complex to get into, just trust me on it, don't bury your triggers unless you have to.


Mr. Einstein used to say that example is not a new method to learn, in fact is the only method to learn. Let me post an example:
#tr {* You try to behead * and miss so badly that you nearly take your own head off.} {behead}
#tr {* As you try to behead *, something distracts you and you only manage to slice his shoulder.} {behead}
#tr {* You swing your * in a perfect arc and neatly behead * The head rolls away with a look of horror upon it.} {--}

These are three triggers on the BEHEAD skill, two of them do the same action, so I assume that I could anchor them as you say?
What will I do is to make a list var and fill it with both messages, then build a #case to trig the behead command?
Ex.
#va bhtrig {* You try to behead * and miss so badly that you nearly take your own head off.|* As you try to behead *, something distracts you and you only manage to slice his shoulder.}
#tr {#case @bhtrig} {behead}

This is how I'd have to build it? This is how it will get faster?

In CMUD, you can't do this - you can't have wildcards inside the list syntax. You'll need to use a regex. Assuming that your patterns didn't have wildcards in, it works like this:

#var something {this is pattern one|this is pattern two}
#trig {{@something}} {behead}

The value of @something is this is pattern one|this is pattern two and the list syntax in trigger patterns is {one|two}, so {@something} gives a proper list pattern.

Also, as we've established in the rest of the thread: don't use stars at the start and end of your pattern unless you need to. In this case, you don't.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
leonardofaoro
Novice


Joined: 07 Feb 2008
Posts: 40
Location: Italy

PostPosted: Thu Mar 20, 2008 7:13 pm   
 
I can't make this trigger without wildcards:
2.97x) As you try to behead the Egyptian elite soldier, something distracts you and you only manage to slice his shoulder.
%dx) As you try to behead %w, something distracts you and you only manage to slice his shoulder. -doesn't work
%a As you try to behead %a, something distracts you and you only manage to slice his shoulder. -deson't work
(%a) As you try to behead (%a), something distracts you and you only manage to slice his shoulder. -doesn't work

* As you try to behead *, something distracts you and you only manage to slice his shoulder. -works
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Thu Mar 20, 2008 8:06 pm   
 
You'll find that leaving out the star at the beginning works fine, too. Since a match can begin anywhere on the line unless you tell it not to, it's superfluous. It's possible to create a more specific pattern that'll match that string (As you try to behead [%w ], something distracts you and you only manage to slice %w shoulder. for example) but you're right - any pattern to match that line will contain a wildcards. Even if they worked, your three other examples also contain wildcards, and so does mine. So you'll need to use a regex, which works slightly differently.

As you try to behead [\w ]+, something distracts you and you only manage to slice \w+ shoulder\.

Is a regex that matches this line. You can put regexes in a stringlist just fine:

#var something {As you try to behead [\w ]+, something distracts you and you only manage to slice \w+ shoulder\.|some other pattern}

But then in your trigger, you need to use () rather than {} to create the list:

#regex {(@something)} {behead}

If you need more info on regex syntax, try here.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Thu Mar 20, 2008 9:56 pm   
 
Quote:
And yes, my machine is slower than most of yours, apparently, or maybe it's that I ran this in 2.20


I ran it in 2.20 too. I get 18 ms running CTRL+Q on my entire system and ALL of my triggers are Regex.
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Fri Mar 21, 2008 5:05 am   
 
I found a great way to demonstrate why you shouldn't use ".*" at the beginning of a line.

You can download The Regex Coach for free to test your regex patterns. Then do the step check and you will be amazed at how many steps it takes to match when you use a greedy star at the beginning of a line. Regex Buddy is better but you have to dish out some cash for it and this one is free.

You can download it at the link below.

http://www.weitz.de/files/regex-coach.exe

Also, using a negated character class is much faster and better than using a greedy or lazy star or plus.
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Fri Mar 21, 2008 6:22 am   
 
Thanks muchly for that link - I new there were free tools out there that did this sort of thing, but never took the time to find one. Excellent work. It'd be ten kinds of awesome if CMUD could include number of steps on the trigger tester tab, but I guess it doesn't need to when there's this, except to save me some copying and pasting.

And yeah, one of the first things I say when people moan about their triggers being slow is to make their patterns better. Most of the time when people use .+ they don't actually don't mean it anyway, and their laziness costs them in match speed. 20ms might not seem a lot, but when you're getting 10 lines a second in combat, that's a fifth of the second wasted before a single line of code is run.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Fri Mar 21, 2008 10:38 am   
 
I found one better...a free demo version of Regex Buddy.

http://www.freedownloadscenter.com/Best/free-regexbuddy.html

Now this program rocks. Just past in your patterns and the line you are trying to match and click debug. It shows you step by step instantly every single step and where it backtracks.

I know after reading the last few hours that ".*" and ".+" will be much slower than ".*?" and ".+?". Adding the question mark makes it lazy not greedy and lazy is faster.

However, I noticed above your pattern of "[\w ]+". This fails much faster than ".+?", but it is twice as slow when matching the correct pattern. I'm also wondering if we can use possessive quantifiers which would make things even more faster since it wouldn't backtrack. Explanation found here: http://www.regular-expressions.info/possessive.html.


Here is an example from the debugger in Regex Buddy.

To match the line "Look this is a test." from the pattern:

Code:
^.* this is a test\.$


It takes this many steps.

Quote:
Beginning match attempt at character 0
[OK]
Look this is a test.
Look this is a test.[backtrack]
Look this is a test
Look this is a test[backtrack]
Look this is a tes
Look this is a tes[backtrack]
Look this is a te
Look this is a te[backtrack]
Look this is a t
Look this is a t[backtrack]
Look this is a
Look this is a [backtrack]
Look this is a
Look this is a
Look this is a t
Look this is a t[backtrack]
Look this is
Look this is [backtrack]
Look this is
Look this is
Look this is [backtrack]
Look this i
Look this i[backtrack]
Look this
Look this [backtrack]
Look this
Look this
Look this [backtrack]
Look thi
Look thi[backtrack]
Look th
Look th[backtrack]
Look t
Look t[backtrack]
Look
Look [backtrack]
Look
Look
Look t
Look th
Look thi
Look this
Look this
Look this i
Look this is
Look this is
Look this is a
Look this is a
Look this is a t
Look this is a te
Look this is a tes
Look this is a test
Look this is a test.
Look this is a test.[OK] <--- 55 steps
[MATCH FOUND]



Now for this pattern:

Code:
^.*? this is is a test\.$


Quote:
Beginning match attempt at character 0
[OK]
[OK]
[backtrack]
L
L[backtrack]
Lo
Lo[backtrack]
Loo
Loo[backtrack]
Look
Look
Look t
Look th
Look thi
Look this
Look this
Look this i
Look this is
Look this is
Look this is a
Look this is a
Look this is a t
Look this is a te
Look this is a tes
Look this is a test
Look this is a test.
Look this is a test.[OK] <---27 steps
[MATCH FOUND]


For pattern:

Code:
^[\w ]+ this is a test\.$

Quote:
Beginning match attempt at character 0
[OK]
Look this is a test
Look this is a test[backtrack]
Look this is a tes
Look this is a tes[backtrack]
Look this is a te
Look this is a te[backtrack]
Look this is a t
Look this is a t[backtrack]
Look this is a
Look this is a
Look this is a t
Look this is a t[backtrack]
Look this is
Look this is [backtrack]
Look this is
Look this is
Look this is [backtrack]
Look this i
Look this i[backtrack]
Look this
Look this [backtrack]
Look this
Look this
Look this [backtrack]
Look thi
Look thi[backtrack]
Look th
Look th[backtrack]
Look t
Look t[backtrack]
Look
Look [backtrack]
Look
Look
Look t
Look th
Look thi
Look this
Look this i
Look this is
Look this is
Look this is a
Look this is a
Look this is a t
Look this is a te
Look this is a tes
Look this is a test
Look this is a test.
Look this is a test.[OK]<---53 steps
[MATCH FOUND]


Now trying to match a partial match on the line "Look this is." we get the following results.

For pattern:

Code:
^.* this is a test\.$


Quote:
Beginning match attempt at character 0
[OK]
Look this is.
Look this is.[backtrack]
Look this is
Look this is[backtrack]
Look this i
Look this i[backtrack]
Look this
Look this [backtrack]
Look this
Look this
Look this [backtrack]
Look thi
Look thi[backtrack]
Look th
Look th[backtrack]
Look t
Look t[backtrack]
Look
Look [backtrack]
Look
Look
Look t
Look th
Look thi
Look this
Look this
Look this i
Look this is
Look this is[backtrack]
Loo
Loo[backtrack]
Lo
Lo[backtrack]
L
L[backtrack]
[OK]
[backtrack] <--- 38 steps
[MATCH ATTEMPT FAILED]



For pattern:

Code:
^.*? this is a test\.$


Quote:
Beginning match attempt at character 0
[OK]
[OK]
[backtrack]
L
L[backtrack]
Lo
Lo[backtrack]
Loo
Loo[backtrack]
Look
Look
Look t
Look th
Look thi
Look this
Look this
Look this i
Look this is
Look this is[backtrack]
Look
Look [backtrack]
Look t
Look t[backtrack]
Look th
Look th[backtrack]
Look thi
Look thi[backtrack]
Look this
Look this
Look this [backtrack]
Look this
Look this [backtrack]
Look this i
Look this i[backtrack]
Look this is
Look this is[backtrack]
Look this is.
Look this is.[backtrack]
[backtrack] <--- 39 steps
[MATCH ATTEMPT FAILED]


For pattern:

Code:
^[\w ]+ this is a test\.$


Quote:
Beginning match attempt at character 0
[OK]
Look this is
Look this is[backtrack]
Look this i
Look this i[backtrack]
Look this
Look this [backtrack]
Look this
Look this
Look this [backtrack]
Look thi
Look thi[backtrack]
Look th
Look th[backtrack]
Look t
Look t[backtrack]
Look
Look [backtrack]
Look
Look
Look t
Look th
Look thi
Look this
Look this
Look this i
Look this is
Look this is[backtrack]
Loo
Loo[backtrack]
Lo
Lo[backtrack]
L
L[backtrack]<----34 steps
[MATCH ATTEMPT FAILED]



Anyway you get the idea. Just imagine if the patter is really long...
Reply with quote
Fang Xianfu
GURU


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

PostPosted: Fri Mar 21, 2008 12:06 pm   
 
Basically, when choosing between match-success speed and match-failure speed, you should think about what's going to happen more often. Apart from stuff like prompt triggers, most triggers are going to be matching rarely compared to the number of times they'll be failing. The trouble with [\w ] in this case is that it's not much better than . for that line, since it contains mostly words. If you tried a totally irrelevant line like a prompt or a channel message, [\w ] will hopefully fail faster.

But I won't make any claims to being much more than passable with regexes, since that's all I've needed for most situations. If you have any more insights (I'd never looked into possessive quantifiers and I'm not sure if CMUD supports them - definitely something to check out, thanks) I'd love to read them.

EDIT: Been reading more about these possessive quantifiers, and they sound awesome. It always bugged me than when you use a construct like [^"]+ you usually follow it with the character in your range, and the engine should've understood that backtracking was pointless in that situation since of course " isn't going to match anything that was previously matched by [^"]. Funky stuff.

EDIT2: Seems like I was right and some regex engines already do that. Ace.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)

Last edited by Fang Xianfu on Sat Mar 22, 2008 2:25 am; edited 1 time in total
Reply with quote
JQuilici
Adept


Joined: 21 Sep 2005
Posts: 250
Location: Austin, TX

PostPosted: Fri Mar 21, 2008 4:44 pm   
 
Based on some simple tests, it looks like possessive quantifiers, atomic groups, etc. ARE supported, at least by the new regex code that's in 2.20. Not surprising, since it's using the updated PCRE library that Vijilante worked up. That means that you can exert some serious control over matching efficiency by writing regexes carefully. I may switch to using regex triggers now, for this very reason.
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you!
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Fri Mar 21, 2008 9:01 pm   
 
The current PCRE library actually supports nearly everything in the Perl 5.10 specifications. As well as some pattern syntaxes that are not part of Perl. Those additions are mostly where a regex feature appeared in another language first and Perl addopted the feature with a slightly different syntax. The things that are in Perl and not supported by the library are only non-matching extensions.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Mon Jul 21, 2008 10:06 am   Re: Anchor triggers
 
Damnit. Just delete this. My connection is in a bad way.
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Mon Jul 21, 2008 11:20 am   
 
When accounting for error, I'd say the numbers aren't statistically significant between regex and trigger patterns, but there's an obvious significant difference between stars and no stars.
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Mon Jul 21, 2008 12:53 pm   Re: Anchor triggers
 
leonardofaoro wrote:

Mr. Einstein used to say that example is not a new method to learn, in fact is the only method to learn. Let me post an example:
#tr {* You try to behead * and miss so badly that you nearly take your own head off.} {behead}
#tr {* As you try to behead *, something distracts you and you only manage to slice his shoulder.} {behead}
#tr {* You swing your * in a perfect arc and neatly behead * The head rolls away with a look of horror upon it.} {--}

#TR{{As you try to|You try to} behead * {and miss so badly that you nearly take your own head off|, something distracts you and you only manage to slice his shoulder}.} {behead}

Anything common to each was left outside of stringlists, including the period at the end. If the end of this trig message is the end of the line, stick a $ there to mark this as well.
The crap at the start of the line
2.97x)
You can forget about, unless you specifically want to capture the stuff to a variable, in which case:
(%d)x~) should work (your error was not using ~ to escape the )
that is to say ")" is a special character, so unless you tell CMUD to treat it as a non-special character, with ~ placed before it, it will treat it as part of your scripting.

However, unless the number is meaningful to you in your trigger commands, just ignore its presence altogether .

Lastly, Vigi said referred to larger numbers of triggers all doing the same thing. That is to say, large numbers (emphasis on large) and doing the same (emphasis on same) thing. Same thing = same commands. The two that send the command to behead are the same. The third is different.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Nicodareus
Wanderer


Joined: 24 Jun 2008
Posts: 68
Location: Texas

PostPosted: Mon Jul 21, 2008 10:58 pm   
 
Vijilante wrote:
There isn't any speed difference between #SWITCH and an #IF else chain. There is a huge legibility difference which is why #SWITCH is often prefered.


No real input here.. I just wanted to point out that this is simply a matter of opinion.. Any language I've ever worked with, I find IF to be far more legible than SWITCH.. :P

Though I do use alot of *s in the few triggers I tend to run.. Sounds like I may need to find a better way to work them out after reading through this thread.. My only problem with that is that the few MUDs I play don't seem to want to match my patterns (Despite the fact that when I test them with text copied verbatim from the MUD, the test says it's okay, but then it doesn't fire in-game when the same exact text actually comes up..) when I try to get specific with them. They don't tend to work until I pop the *s in there. Pretty frustrating. Most of the hassle I get seems to come from trying to escape out parentheses and brackets in my patterns.. For example, one MUD I play, I try to forward various channels into another window..

[OOC] Blah: This is a test.

If I try to match ~[OOC~] * and then past in [OOC] Blah: This is a test. to the trigger test, it says it matches fine. But the trigger never matches in-game, no matter how I try to tune the settings on the specific trigger.. (Match on prompt, match on newline, etc, etc).. I can even #echo the exact same text coming form the MUD and the trigger will fire on the echo, but not on the actual text from the game. But if I change it to *OOC*, it matches. Which really irritates me, because I don't want it to have to work this way, especially since it tends to eat various messages that contain the word OOC for obvious reasons.

And yeah, I know the first response I'll get will be 'What triggers are you using and what text is coming form the MUD, etc, etc' which I can't really answer right this moment. Mainly, I'm just hoping someone might have a general idea on why this isn't working..
Reply with quote
Llwethen
Novice


Joined: 08 Dec 2006
Posts: 37
Location: Lancaster,Oh

PostPosted: Tue Jul 22, 2008 1:30 pm   
 
Interesting thread. Seems like changing the test patten

Code:
^[\w ]+ this is a test\.$


to
Code:
^[\w]+ this is a test\.$


Produced quite a speed up for match and failure when testing in the regex coach.
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Wed Jul 23, 2008 10:36 am   
 
There are only two obvious possibilities.

1. Your patterns are wrong, or
2. Your mud is not normal, and is sending something strange (every line being sent like a prompt or something similar. Try playing around with the 'new line' and 'prompt' options in the trigs.

Also, when you can, post examples of the mud output with the xml of the trigger that won't fire.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Wed Jul 23, 2008 12:47 pm   
 
Caled appears to be directing his message to Nicodareus. Yeah, we might need the debug output too, but I think it should go into a different thread since it is not related to speed.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
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