On a 150k Aetolia system... I get a score of 10. On a blank setting file... 0.5 go me.

ctrl-q does accurately not show you how fast your system is processing...on my crappy P2 350mhz comp, I get a rating of over 100, but after testing and timing, my system proved to be processing exactly 15 times faster than someone else with a fancy new computer who had a rate of 10, cause of the coding I guess.

That didnt make sense to me.

"I get a rating of over 100, but after testing and timing, my system proved to be processing exactly 15 times faster than someone else with a fancy new computer who had a rate of 10..."

So if this "someone else" and their "fancy new computer" got a rate of 10, and you got exactly 15 times faster than this "someone else".. then you got a score of .6666 WITH a system?

It depends on how you set up your triggers, I believe, not on how quick your computer can process it. So if you have a lot of triggers that are delimited by line beginning/end, a lot of those triggers will get ignored as soon as it detects abc and realises it doesn't match.

The slowness comes from the fact that, regardless of whether it all matches or not, if you have a trigger like "^ad$" it will still check to see if the next character after the a is a d or not.

Lodin...that's exactly why I said ctrl-q doesn't accurately show how fast your system is, I really can't see how this is so hard to understand .

Does anyone else think that its weird that Thorgal got a .6 WITH a system? I dont even get that score when my settings are EMPTY.

My god you are daft, try rereading the entire thing again, including Drago's post.

"ctrl-q does accurately not show you how fast your system is processing...on my crappy P2 350mhz comp, I get a rating of over 100, but after testing and timing, my system proved to be processing exactly 15 times faster than someone else with a fancy new computer who had a rate of 10, cause of the coding I guess."

I understand what Drago was saying, and i understand what you're saying too, but it doesnt sound right to me. Say i were to compare my system with PersonA. if we had identical machines and I were to get a faster score than PersonA, could i not then say that my system ran faster than PersonAs system? If both our systems cured just as many afflictions, then if i get a faster score it means that mine was coded in a more efficient manner.

You mentioned that your pentium 2 "after testing and timing" was able to go from a score of "over 100" to "15 times faster than someone else with a fancy new computer who had a rate of 10". This doesnt mean that Ctrl-Q wasnt accurate or anything, it just means that the other persons system sucked compared to yours.

The Ctrl-Q function was written by zugg himself as a way to benchmark the different versions of zmud and test the speed improvements. I doubt he would include something that wasnt accurate.

oh and by the way, on my xp1700+ here i never get below 1 on a totally empty settings file. I am interested in knowing what methods you used to speed up your system and settings by 151x.

I'm sure it's great at that, but that has nothing to do with comparing systems or comparing how fast a system will respond to something from the server.

To check that, you'd have to write a telnet server that spit out test strings and timed the response, then run it on your the same machine as zmud (or on a LAN with a small, constant, and measurable latency). Ctrl-q is good arm-waving material but it doesn't say who will get the apply liniment in faster.

Let me say that again:

You pointed it out right, Lodin, Zugg coded in CTRL-Q to demonstrate how fast -overall- matching of trigger is.
That is, if you have a one-line trigger, that one gets checked for a match every time you see one line of mud output. Faster computers will be able to output 100 lines of mud output faster than a slow computer, because it'll be able to check that one-line trigger 100 times for a match faster than the slow one. Obviously.

That -doesn't- tell you THAT much about the actualy performance of your curing system though. It only tells you how long your computer takes to match all relevant triggers against 1 line of mud output, but not how long it takes to actually initiate curing or whatever it does as soon as you get an affliction message. If you want to see that and calculate speed differences between -different- curing systems, you need a log, because it's the only way to measure the response time properly.

As I said in one of my first posts, I'm not saying CTRL-Q is useless, it does tell you something about overall speed. But it doesn't actually tell you whether your curing system is performing faster than some other system.

-contentsigh- Exactly. Oh, and all it takes to make an uberfast system, is making sure not using any other wildcards in your triggers than (*), making sure triggers are only active when they actually have to be active, and don't use stringlists if you don't really have to, if ya do all that, you can stand in a room with 80 people spamming to hell and back without getting any lag.

Actually the * wildcard is the slowest of all the wildcards. Having no wildcards is fastest, and having the most broad and general wildcards (such as *) is slowest. In general, the more specific your wildcard, the faster it can match lines. The * wildcard is the one you want to avoid at all costs if you can.

Edit: You also want to avoid multiline triggers using the $ symbol. Instead, use trigger states.

Ok sure, just confuse me. I've seen in a few places someone say (*) was quicker than %w

Although now that you say it, it does makes sense that a smaller search field would be quicker than a general one, unless that smaller search field is laden with code and conditions.

There was a post on the zuggsoft forums where lightbulb was explaining trigger matching speeds based on the way the pattern was defined, and he did point out that the fastest triggers were the ones that were the most specific.

well...
If you want to have fast speed, use regular expressions, as they're generally parsed faster than zmud's own syntax, in my experience.
And as for more-specific-is-faster, well, it's obvious, isn't it?
The more specific, the sooner the trigger matching process will find a criteria that doesn't fit to the trigger you try to match, and the sooner it can switch to the next trigger. If you have a * wildcard which can apparently cover several lines for some reason you end up giving zmud more work, ergo slow it down.

Generally, the fewer wildcards you have and the more specific they are the faster it'll be, I'd say. At least that's my impression so far.

zmud is slow.

I actually did tests on my computer using Wintin, MushClient and Zmud timing the attack of my swings. V.5.55 of zmud was slower, but v.7.05 was just as fast as the others. I found the speed of my computer and the strenght of my internet connection (wireless, or lan, or wireless in the recess of my school's computer lab) had more affect than the client I used.

Computers are so fast these days it amazes me that any of these systems still have lag, considering its all text!

Well, MS and co are quite busy adding all kinds of nonsense that slows yer system down again 'tis called "tryin' ter be a step ahead o' progress"

Though, just think for a moment how many triggers your zmud is matching every fraction of a second. I mean, I'd guess I get like 30 lines of mud output per second at least, and every of those lines is matched against ALL your active triggers at least initially. If you have a prompt trigger, that runs every time you see a prompt. I guess you'd take an hour to write down all the operations zmud does in no more than 5 seconds. 'tis amazing, isn't it?