I have, in the last few months, experienced Mudlet's limit with trigger parsing/script execution speed.
Before I continue, the system I am running is maintained by another, though I have added a lot of scripts of my own, and expanded the GUI a lot.
To test what appeared to be Mudlet becoming laggy, jerky, and at times unstable to the point of freezing up for several seconds at a time, I worked out a way to get the mud to send huge amounts of lines all at once.
1. In Aetolia. gmcp on
2. Config mapview on (this causes an ascii map to be sent with every movement/look)
3. Ride a horse.
4. Move to a 'straight' of several rooms.
5. type "gallop se ; gallop nw" into the command line
6. hold down enter for a few seconds.
This causes mudlet to lock up, and sometimes for the text to appear scrambled. I've been told that this is how raw gmcp looks.
I then go through my triggers, deactivating trigger groups and repeating the test. Vast improvements can be seen.
I see a similar improvement when I disable some of the gmcp event handler scripts (for room items in particular).
I can use this information to try and locate specific scripts/triggers that are problematic, but there are so many of them and because a large part of my stuff is maintained by another (a bought curing system in other words), it is difficult for me to get changes done to some of it - I basically need to prove that specific triggers or functions are problematic.
So, finally - my request for help!
Is there a script I could write which will simulate feeding vast amounts of lines to mudlet for a few seconds, and return some figure that I can use as a measurement? In this way I could measure much more precisely than "oh, I think mudlet was more stable this time I galloped."
measuring parser speed
Re: measuring parser speed
Try disabling MCCP and see if you can reproduce it.
Re: measuring parser speed
Hi Fetaera!
Thanks for that.
It is actually significantly better. It's not getting all scrambled, though I can still notice a difference if I disable all 3 of the problem groups (offensive trigs, curing trigs, and room items event handler).
There were essentially 2 symptoms during the galloping test:
1. the previously mentioned garbled output, requiring a mudlet restart
2. watching the mudlet mapper trying to keep up with the swift movement. In a gallop nw;gallop se, I end up back in the original room. At worst it doesn't show any of the moment at all, and at best you can see it (however briefly) pass through each of the rooms displayed by the map.
Disabling any one of the three groups of settings I mentioned above, stopped (1) occurring.
Disabling another group made the mapper pretty good but still skip a few rooms .
Disabling the third made it the way I remember mudlet being when I used my own system.
Turning MCCP off, has made the mapper behave like the middle one above. So! Still room for improvement, and a measurement would still be handy, but in the mean time I'm hoping group fights will be manageable again.
Just by turning mccp off though, it is behaving much, much better.
I'll pass the word around, thanks.
Thanks for that.
It is actually significantly better. It's not getting all scrambled, though I can still notice a difference if I disable all 3 of the problem groups (offensive trigs, curing trigs, and room items event handler).
There were essentially 2 symptoms during the galloping test:
1. the previously mentioned garbled output, requiring a mudlet restart
2. watching the mudlet mapper trying to keep up with the swift movement. In a gallop nw;gallop se, I end up back in the original room. At worst it doesn't show any of the moment at all, and at best you can see it (however briefly) pass through each of the rooms displayed by the map.
Disabling any one of the three groups of settings I mentioned above, stopped (1) occurring.
Disabling another group made the mapper pretty good but still skip a few rooms .
Disabling the third made it the way I remember mudlet being when I used my own system.
Turning MCCP off, has made the mapper behave like the middle one above. So! Still room for improvement, and a measurement would still be handy, but in the mean time I'm hoping group fights will be manageable again.
Just by turning mccp off though, it is behaving much, much better.
I'll pass the word around, thanks.
Re: measuring parser speed
Parsing speed implies there is a problem with the trigger speed maching. I don't think it is that - it sounds like you have issues with efficiency in your scripts. Nothing to do with Mudlet and all to do with how well you code them.
Re: measuring parser speed
I agree. Sorry, I thought I made it clear that I'm not blaming Mudlet. I think it is a combination of both bad scripting and bad trigger patterns actually, as his trigger patterns are poorly done as well.Vadi wrote:Parsing speed implies there is a problem with the trigger speed maching. I don't think it is that - it sounds like you have issues with efficiency in your scripts. Nothing to do with Mudlet and all to do with how well you code them.
He says he can't replicate it on his computer, which is apparently much more powerful than mine. Mine being a haswell core i5 with 8gb ram. My own system used to handle large team fights on an atom netbook, which is a reason why I am skeptical.
I ought to be able to use feedTriggers to send 1000 lines of text to mudlet, and measure how long it takes to get to the end, right?
Then I have a number value which I can record and compare relatively after making changes, until I've narrowed down problem areas?
Re: measuring parser speed
Er, addition to above.
I got into a medium sized team fight today (4 vs 5) and it was better than it has been thanks to the MCCP suggestion, but there were a few moments when the text stopped flying past and went really slowly, so I definitely still need to find the problem areas and optimise.
I got into a medium sized team fight today (4 vs 5) and it was better than it has been thanks to the MCCP suggestion, but there were a few moments when the text stopped flying past and went really slowly, so I definitely still need to find the problem areas and optimise.
Re: measuring parser speed
Yeah, try feedTriggers.
Re: measuring parser speed
Sounds like you have tripwire. Many people have this issue and it creates more problems than it should. I can not code or I would fix it. But if you should find the issue in the system please can you share with us all. I know of at least five people who can not fight now because the system is lagging up so much mid-fight. I am upset as I bought the system after being told it has support and it took ages to save up for too. 
Re: measuring parser speed
Leah:
I wrote a script, if you have tripwire it is easy as TW has its own timing framework built in.
! is TW's built in lua-from-the-commandline alias, but it also returns how many milliseconds it takes to run the script.
In the case of the above, 1000 lines and 1000 blank lines, is taking approximately 50ms to run if I disable all triggers. Immediately after login, with all triggers enabled, it is 1000ms, after 5 minutes of playing the game (defup etc) it increases to 1500ms, and if I add my own triggers (personal folder) it increases to 1700.
I've been through all of the trigger groups - this following list is the result when each of the trigger groups is disabled (only one at a time).
stock TW 1017ms
bashing 995ms
utility 986ms
curing 875ms
combat 693ms
defenses 750ms
prompt actions 1017ms
mapper 990ms
class spec 1000ms
questing 1017ms
It actually seems directly proportional to the number of triggers in each group. I've delved into the combat group further, trying to locate specific problem triggers, but each trigger appears to contribute equally.
If I can motivate myself, I'll go through and do this for one of the trig groups, just to see if it helps:
a) fix up the regex patterns, which are far too lazy
b) add non-regex gates to them
If I find the problem, I'll post it back in the clan/Aet forum. Kaeus is aware of the problem, but says he can't reproduce it, which is why he hasn't fixed it yet.
I wrote a script, if you have tripwire it is easy as TW has its own timing framework built in.
From the command line, type: "!crtlK()"
! is TW's built in lua-from-the-commandline alias, but it also returns how many milliseconds it takes to run the script.
In the case of the above, 1000 lines and 1000 blank lines, is taking approximately 50ms to run if I disable all triggers. Immediately after login, with all triggers enabled, it is 1000ms, after 5 minutes of playing the game (defup etc) it increases to 1500ms, and if I add my own triggers (personal folder) it increases to 1700.
I've been through all of the trigger groups - this following list is the result when each of the trigger groups is disabled (only one at a time).
stock TW 1017ms
bashing 995ms
utility 986ms
curing 875ms
combat 693ms
defenses 750ms
prompt actions 1017ms
mapper 990ms
class spec 1000ms
questing 1017ms
It actually seems directly proportional to the number of triggers in each group. I've delved into the combat group further, trying to locate specific problem triggers, but each trigger appears to contribute equally.
If I can motivate myself, I'll go through and do this for one of the trig groups, just to see if it helps:
a) fix up the regex patterns, which are far too lazy
b) add non-regex gates to them
If I find the problem, I'll post it back in the clan/Aet forum. Kaeus is aware of the problem, but says he can't reproduce it, which is why he hasn't fixed it yet.
Re: measuring parser speed
I don't think it is related to the triggers. Look into the scripting. Triggers wouldn't be getting slower and slower as time goes on, but scripts could be.