Zugg Software :: View topic

Apprentice Joined: 18 Feb 2007 Posts: 190

about 2/3 of my zmud session functionality had been rewrote and heavily optimized for cmud, scripts itself execute _much_ faster...
however, output is sluggish and moving feels choked, unlike zmud where everything except scripts feel crisp

to compare:
zmud: Aliases: 192, Triggers: 165, Macros: 52, Vars: 71
cmud: hadnt got to com yet, but about 2/3 of above aliases and triggers, much more vars, all triggers optimized as much as possible, patterns transferred from zmud gave horrible results

(refresh rate set 100 on both)
zmud speedtest: 3.3-4.5 up to 6 on a bad day
cmud speedtest: 14.5 on a good day, 15-17 on avg

movement (delta from sent direction to processing prompt):
zmud: 180-220ms
cmud: 420-550ms

im not happy with those results, general speed needs serious improvements Sad

update: disabling all status elements and gauges drops move delta to 350-430ms avg, but has no effect on speedtest, so inefficiency of gauges/satus bar contributes 1/3 move delta overhead alone

Posted: Mon Oct 20, 2008 1:12 pm

The reason for this is most likely because zMUD didn't wait for triggers to process before displaying more lines. I'm sure you can imagine the horrors that caused with the text running off ahead while your scripts are still trying to BASH MAN IN HEAD. In CMUD, the next line isn't displayed until your scripts have finished executing, so lines display at the speed of your scripts rather than as fast as they can be pushed out.

I doubt this particular behaviour will change in CMUD, but that doesn't mean that more can't be done to improve it.

Apprentice Joined: 18 Feb 2007 Posts: 190

this is not the case (as a side note this was never the case with _my_ scripts Razz

), all scripts that are actually _running/fired_ while moving are room, exits and prompt triggers, those been timed and take less than 100ms per 1000 executions (combined), this is purely regex engine/trigger matching/buffer memory access issue

anyway, i seem to did it this time, while moving things around cmud crashed corrupting session package, since then every attempt to recover it failed, and i aint gonna dig in it with sqliteadmin. so much you get for trusting scintilla editor/cmud package manager instead ol'notepad2, nice one, bah!

edit: to reiterate previous statement, triggers that are _not_fired_ create LAG, not running scripts.

Apprentice Joined: 18 Feb 2007 Posts: 190

ok, localized main issue, #GAG Exclamation

gaging (no other processing done), of 17 lines causes 100-150ms delay
additionally, triggers generated by mapper (or their generation) results in additional 40+ms

#GAG needs some heavy optimizations it seems

Posted: Tue Oct 21, 2008 6:53 pm

Post your exact testing scripts so that we can play with them. #GAG *was* recently optimized, so I'm surprised it causes such a slowdown, especially compared to how #GAG was done in zMUD. But #GAG does require the screen to be updated, which is like refreshing a button. The screen refresh has to be done in the main thread, and depending upon your video driver and Windows version, it can be slow or fast. For example, Vista screen refreshes are much slower than WinXP screen refreshes.

And yes, anything with the mapper should be ignored for any performance testing since that is being rewritten. Since the mapper was directly ported from zMUD, it only runs in the main thread and has none of the CMUD optimizations in it.

Finally, CMUD uses the latest version of the PCRE open-source regex library. zMUD uses an older version. The older version was faster for some situations, but had more limits on memory usage and various advanced features. Vijilante can probably better address regex speeds since he has worked a lot on the compiling of PCRE to best meet the needs for CMUD. But we'd need to see the exact trigger patterns that you are using to really comment on the PCRE speed.

Apprentice Joined: 18 Feb 2007 Posts: 190

thanks for reply master z.
heh, im running winxp on 2ghz athlon 1gb ram and onboard gfx (sis741/661) which has very limited dx capabilities, so that might be graphic performance issue, depending how cmud handles display...

my culprits are

Apprentice Joined: 18 Feb 2007 Posts: 190

regarding regexes, not sure whether there actually is issue, #cmd speedtest is hardly a reliable benchmark and i havent got anything to real working order yet, however, my zmud runs more of less optimized triggers in half cmud mark, or less, (after manually recreating package by ripping corrupted one with sqlite admin things go faster now - strange, marks 9-10 so far)

from what i keep enabled at all times and are most demanding

group of /^(\w+) something happened to him\.$/ type triggers
and one 'open' trigger /\shas fleed!$/

but generally, bulk of (double anchored) literals, or grabbing one/more \w+ or\d+ from middle of literal has _much_ more impact on speedtest in cmud

Posted: Tue Oct 21, 2008 11:21 pm

Posted: Wed Oct 22, 2008 12:11 am

One suggestion I would make is the use of #GAGON and #GAGOFF in place of the gag in mapstart and the gag in mapend. At least, that's how I have my minimap for Aardwolf working.

Essentially, CMUD is having to redraw the screen multiple times while processing the information between the tags. With #GAGON, it gags all incoming output from the window until #GAGOFF is reached. I normally put #GAGOFF twice at the end to make sure it does turn off. You may need to keep a #GAG for the mapend tag, though, as that seems to invariably go through.

Anyway, that should help performance-wise quite a bit.

Charneus

Apprentice Joined: 18 Feb 2007 Posts: 190

charneus, tested gagon/off on both z/cmud, on c theres no performance difference, on z i dont remember but i ended up with normal gag anyway.

fang, nope mate, cant stuff anything non-low profile to slim tower, and i have planned system upgrade after first price slash of core i7 (they have to come out)
but even then i tho about onboard gfx and putting new stuff up old box

----

so ive been playing with it a bit more, gagging whole speedtest (#TR {^abcde} {#GAG} "" regex|notrig) raises zmud mark by 1-1.5 and cmuds by 4+... interesting

anyway, probably should bold that, why is cmuds screen drawing so much slower than zmuds (on the very same machine/system), dosnt it use standard gdi functions? (compared easly by moving mouse over open menus, well, if you have all graphic 'enhancing' 'features' disabled in win)

Posted: Wed Oct 22, 2008 4:32 pm

Moving the mouse over menus isn't a good test. zMUD and CMUD use completely different menu/toolbar systems. The system used in CMUD allows for the end-user menu customization, and it *is* slower in it's redrawing than the menu/toolbar system used in zMUD.

The component that actually scrolls text from the MUD (the main MUD window) is the same between zMUD and CMUD, except that CMUD has a few fixes, additions to MXP, and better optimization for #GAG (so that deleted lines don't get displayed momentarily causing flicker).

Also keep in mind that the Ctrl-Q speed test displays different values in zMUD and CMUD and CMUD uses a more reliable way to test the speed. CMUD uses the high-precision timers in Windows, while zMUD just used the Window "tick" value.

Apprentice Joined: 18 Feb 2007 Posts: 190

cheers!
for now ive been sitting in debugger a bit, and i must say, SWEET! Very Happy

(and i dont use capitals on forums lightly)

i yet have to localize the issue tho, seems that gag itself is not the cause

i have minor (but extremely useful) feature request tho, i start a thread with it

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Hrm, it does look like there is something that requires optimization by Zugg here. My standard for saying such a thing is when a loop does not produce a clean linear progression versus time. I have a wonderfully slow old system that is great for finding these things.

Starting with a blank session in a fresh launch; I pasted the triggers you posted above into class for ease of editting the XML. I then ran the CTRL-Q test in the main window to fill its buffer, and entered "#WIN minimap" at the command line. I rand the CTRL-Q test in that window so that its buffer would also be filled. Filling the buffer is necessary to isolate display and processing routines away from the memory allocation routines.

Next can the actuall speed tests. Using this in the main command line

Apprentice Joined: 18 Feb 2007 Posts: 190

well, if you havent disabled #addk part you are allocating over 2000 memory blocks in #loo 1000 run and also calling 1000 recalculations of hash tree, which would be expected to slow down with size Very Happy

for 1000 lines we should probably use %arrset instead Wink

btw: i also got small speed increase by changing minimap.index to normal variable (minimapindex doh, my creativity)

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Further testing showed the problem to be in the combination of lines "#ADDK minimap @minimap.index %line;#ADD minimap.index 1" in your ID_MMAP trigger to be the source of the problem. When I seperated the index into its own variable a linear progression was restored.

I will post my full script design reccommendation in a few minutes after I rebuild it.

In my complete testing of this I did manage to cause a rather nasty crash, which resulted in an untrappable AV. Evidently CMud somehow managed to start executing code in a memory range that it didn't own. I will see if I can track down a procedure for that crash.

Apprentice Joined: 18 Feb 2007 Posts: 190

lol, nice one :D

Apprentice Joined: 18 Feb 2007 Posts: 190

btw.
i also tried ^(.*)$ -> #ADDK minimap @index %1
%line seems to be fastest option, but since i only need the minimap variable populated on very specific (and rare) occasions i will look into extracting it, hmm, probably by %roomflag check in onroomenter...

main cause of slowdown seems to be autotrigger created by mapper anyway, somehow i managed to brake that while disabling triggers and that gave (semi)false positive on gagging, but fix for that is thankfully coming soon (with new mapper) Very Happy

Apprentice Joined: 18 Feb 2007 Posts: 190

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Ok. The final recommendation. Create a seperate package by the name of MiniMap containing exactly this. Then include that package into your session.

Apprentice Joined: 18 Feb 2007 Posts: 190

whistle, your package got me AV at first shoot :P
Cool

actually, it completely messed up my settings too, not to mention default toolbar layout Laughing

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Replicating that AV down to a very small procedure is seeming quite difficult. Right now the best I have is to import the script above into a blank session, then set the MMap module to Local. Running the my speed testing command line, from a few posts ago, twice cosistently produces the untrapped AV.

So far it looks to be a rare set of circumstances when text is sent between 2 windows and multiples #GAG's occur.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I think you will have to describe the EXACT method you used to import what I posted. I tested it about 16 different ways to make sure it wasn't tripping the AV currently, while I tried to find a clear procedure for the bug.

If you found a clear path to the bug using the code I posted then that is very important. As I implied, it is proving to be difficult to design a set of circumstances to replicate this bug as an isolation. Every detail that is added helps in isolating the bug. If your procedure produces a different error point and behavior then I have been seeing then that is also helpful. Knowing that more than 1 bug is in play on this script would go a long way to trying to produce a procedure for Zugg.

Please post some details. Right now I don't have have anything solid enough to make into a distinct bug report.

Apprentice Joined: 18 Feb 2007 Posts: 190

well mate, annoying thing with those packages is, almost every time i do something related to them i cause av, and in best case lose toolbar layout, then possibly rest of window preferences, in worst all settings (now doing xml exports every major change, just like zmud times before i siwtched to notepad :P, unfortunately this dosnt work for windows preferences)

ok, created package, just like you wrote, minimap, pasted all to xml, changed > to > etc, disabled and renamed my triggers, (kinda forgot to destroy old window, might be related)... tried moving, unhandled av, corrupted settings and all...

off to bed, will play with it tmrw

Apprentice Joined: 18 Feb 2007 Posts: 190

that (or another) av seems to be related to invisible vars bug i posted
ie. you move things around between packages but they retain all properties from original package

anyway, after recovering from last crash... i recreated all your triggers in the main package, after little fiddling i got it to work fine, with one exception, having them in main package slightly decreased performance even versus my original design (your packaged version was 6us better on avg per trig execution)...

so of course, i decided to investigate and created package and moved things to it,, things got wonky so i did session restart, ofcoure, lost layout and preferences...
more over, moved window suddenly started to announce its triggers to main session

i dont remember what i did at this point, but from past experience, everything is messed up already in memory and its just matter of time for av (random, mostly handled but settings destroyed anyway) to happen, granted, i got unhandled

edit: oh yeah, i tried to close session Razz

just got similar

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Let's try to isolate a few of these things into seperate problems.

This is the EXACT procedure I used to successfully import the script above.
1. Highlight the script and copy it
2. Launch CMud
3. Close Sessions window (ESC)
4. Open Package Editor (CTRL-G)
5. Select File|New Package from the PE menu
6. Use a name of "x" for the package
7. Click the XML tab for the module x
8. Paste the script in below the actual module XML
9. Make the 5 edits required, and copy the editted script to the clipboard
10. Click the Cancel button
11. Right-click in the tree panel and select Paste from the context menu
12. Right-click on the x module in the tree panel and select delete
13. Close CMud
14. Rename the x.pkg file to what I want, and put it where I want it.

Using the testing loop above with a loop count of 1000 as step 12a in my procedure, I consistently get timings of 2100. That is better then the timings I got with a loop count of 200 and your original triggers.

Now do you think you could post an exact procedure for how you generated a crash just preforming the import.

Also it needs to be noted that there is a big difference between a crash, and an unhandled AV. The unhandled AV gives little box that says program terminated and as soon as you click OK, CMud is gone. A crash gives a full dialog and lets you prepare and send a crash report.