Gammon Forum : MUSHclient : General : Benchmarks

Log on

Gammon Forum

Entire forum

MUSHclient

General

Benchmarks

Benchmarks

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

Pages: 1 2

Posted by

Nick Gammon Australia (23,001 posts)

bio Forum Administrator

Date

Reply #15 on Mon 19 Jul 2010 09:21 PM (UTC)

Message

Hmmm, that's odd. You are right David, it looks like that, however I thought MUSHclient used to do what Mudlet seems to be doing right now.

Basically GUI applications tend to work like this:

Some change happens (eg. new data arrives)
Some or all of the output window is marked for redraw (ie. invalidated)
The OS generates an Update event once it finds part of the window is "invalid"
The client clears some or all of the output window and redraws the new information

The point is however, that the Update event is generally low priority. So you may get the first couple of steps (process a change, mark more and more of the window as invalid) many times, before, in a quiet moment (an Idle moment) the Update is generated.

This is generally much more efficient, so that if you have (say) 100 lines arriving, you don't redraw the whole screen 100 times, you add the 100 lines to the output buffer and draw it once.

Visually (and in my own tests too) it seems that MUSHclient is redrawing more often than I would expect, thus giving the effect of scrolling text, whereas Mudlet seems to be (arguably more correctly) drawing in batches. Of course, you may well prefer the scrolling look, but I thought that was what the "smoother scrolling" global option in MUSHclient was supposed to do.

I better look into that.

Mind you, in both cases the text is drawn really fast, and you could make out at case that the Mudlet approach of chunking it up actually makes it hard to see quickly-arriving text (which may be important). However as MUSHclient used to do the same, I wouldn't mark them down for that, and they may have an option to draw differently.

As for how I set up my test, these days it is hard to find a Unix box with telnet enabled (because of security concerns) and ordinary MUD servers tend to "throttle" output, so I adapted my "tiny MUD server" to just read a file and dump it to the client. If anyone wants a copy I can post it.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Nick Gammon Australia (23,001 posts)

bio Forum Administrator

Date

Reply #16 on Mon 19 Jul 2010 09:35 PM (UTC)

Message

After setting some breakpoints, it seems that the code is not running unexpected UpdateWindow calls.

I'm not sure why it seems to be redrawing more often than I would expect. I have to guess that earlier versions did InvalidateRect (which invalidates part of the window) whereas now it does Invalidate (which invalidates the whole window).

The invalidation of the whole window is part of the change made for miniwindows, because you can't "scroll" a miniwindow upwards when you receive a new line.

Prior to miniwindows, this is what would happen. Say you had 25 lines of text on the screen...

A new line arrives
The output window was scrolled upwards (a bit-blit sort of scroll built into the operating system API) by one line height. This made the existing text move up a line (and the top line would disappear)
The bottom line area rectangle was invalidated (with InvalidateRect) so that line only was marked for redraw.
Eventually on an Update event the invalidated parts would be redrawn.

Of course, on more lines arriving the OS would scroll up the invalidated rectangles internally, so that the invalidated area would get larger.

I just have to guess that Invalidate must generate a higher-priority update event than InvalidateRect. A bit more testing might throw some light on this.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Nick Gammon Australia (23,001 posts)

bio Forum Administrator

Date

Reply #17 on Mon 19 Jul 2010 10:04 PM (UTC)

Message

Well now I'm puzzled.

Adding an extra metric into MUSHclient shows how many times the OnDraw function is called to draw the output window.

Testing it with the high.txt file (5378 lines) puts 5416 lines into the output buffer (OK, some probably wrapped so that accounts for the extra lines).

However the OnDraw routine was called 159 times (that is, we got 159 Update events). So it certainly didn't wait until the end, nor did it do an update per line. Or even per screenfull, as the screen was about 58 lines in height.

Nor does there seem to be a direct relationship between the number of packets received and the times the screen was redrawn. It appears to be redrawn about every 2750 bytes, however the packet size was 1000 from this particular server.

My best guess is that Windows is noticing the Invalidate events and pumping out Update events to force a redraw at some sort of interval, not necessarily directly related to anything else. However not knowing the exact data flow at the TCP/IP level, maybe those 159 redraws happened to coincide with a short break in the incoming data, thus making the Update event the highest priority one at the time.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Twisol USA (2,257 posts)

bio

Date

Reply #18 on Mon 19 Jul 2010 10:50 PM (UTC)

Amended on Mon 19 Jul 2010 10:54 PM (UTC) by Twisol

Message

Nick Gammon said:
maybe those 159 redraws happened to coincide with a short break in the incoming data, thus making the Update event the highest priority one at the time.

I think this is probably most likely, though I'm not sure about the "priority" bit. From what I've read so far, the message queue doesn't seem to be prioritized, though there are a handful of window messages that bypass the queue (and SendMessage() will also do this). I think you're just seeing the result of the order the events happened to be posted in, and I wouldn't be surprised if you got different results if you tested again.

edit-before-post: Also, MSDN says this about InvalidateRect():

Quote:
The system sends a WM_PAINT message to a window whenever its update region is not empty and there are no other messages in the application queue for that window.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

Nick Gammon Australia (23,001 posts)

bio Forum Administrator

Date

Reply #19 on Mon 19 Jul 2010 11:11 PM (UTC)

Message

Twisol said:

Also, MSDN says this about InvalidateRect():

Quote:
The system sends a WM_PAINT message to a window whenever its update region is not empty and there are no other messages in the application queue for that window.

Effectively, this make the WM_PAINT message a low priority, which is what I meant. It gets done if nothing more important needs doing. I didn't mean there was some sort of "priority sequence" just that updating the window is a low priority.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Twisol USA (2,257 posts)

bio

Date

Reply #20 on Mon 19 Jul 2010 11:32 PM (UTC)

Message

Yeah, so you were right. Hope I helped to at least clear up your puzzlement a bit, though.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

Vadi (4 posts)

bio

Date

Reply #21 on Tue 20 Jul 2010 02:28 AM (UTC)

Message

Please do post the server script thing! Something for all to test against would be nice.

top

Posted by Nick Gammon Australia (23,001 posts) bio Forum Administrator

Date Reply #22 on Tue 20 Jul 2010 04:34 AM (UTC)

Message

The version I amended is here:

http://www.gammon.com.au/files/muds/tinymudserver_v2.1.tgz (15745 bytes)

I updated tinymudserver_v2 to compile under recent versions of gcc. This one is only a single .cpp file (I think I overlooked I had a more modern one, oh well).

Just type "make" to build it, and then ./tinymudserver to run it.

Then fire up your client (eg. to localhost or wherever you have the server running).

Make a new character (type "new") and give a name and password.

Then once connected type "send xxx" to simply open file xxx and dump to the client.

I just grabbed the files mentioned in the benchmarks post, eg.


wget http://www.gammon.com.au/mushclient/termcap
wget http://www.gammon.com.au/mushclient/high.txt

So to test in the client you connect as described above and type:


send high.txt
send termcap

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Fiendish USA (2,518 posts)

bio Global Moderator

Date

Reply #23 on Wed 21 Jul 2010 10:29 PM (UTC)

Message

Quote:
I realize that with todays hardware and todays bandwidth, performance really isn't too critical on a mudclient

I wish this were true. Lua scripting performance is still far too slow for my liking, even on brand new hardware. :(

https://github.com/fiendish/aardwolfclientpackage

top

Posted by

David Haley USA (3,881 posts)

bio

Date

Reply #24 on Wed 21 Jul 2010 11:06 PM (UTC)

Message

Fiendish said:

Quote:
I realize that with todays hardware and todays bandwidth, performance really isn't too critical on a mudclient

I wish this were true. Lua scripting performance is still far too slow for my liking, even on brand new hardware. :(

This is a rather surprising claim, to say the least, considering that Lua is used to satisfaction on embedded devices and in 3D games, which have far higher performance needs than MUD clients.

What kind of thing are you trying to do for which Lua is too slow?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

top

Posted by

Twisol USA (2,257 posts)

bio

Date

Reply #25 on Wed 21 Jul 2010 11:19 PM (UTC)

Message

It's more likely that the algorithm being used is inefficient or slow in some way (perhaps a hidden bottleneck). The core Lua language is extremely fast!

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

top

Posted by

Nick Gammon Australia (23,001 posts)

bio Forum Administrator

Date

Reply #26 on Thu 22 Jul 2010 12:24 AM (UTC)

Message

When I was playing around with rendering 3D scenes for Aardwolf, as described in http://www.gammon.com.au/forum/bbshowpost.php?id=10346&page=2, I was pleasantly surprised to see that not only was the scene rendered in under a second, I was getting quite a good frame rate (I think around 25 FPS). And this was individually addressing each pixel (with WindowSetPixel)! Not only was that a lot of pixels, but there was quite a bit of maths behind working out what pixel to set, where.

Other things I have done in Lua, like the spellchecker, also work very fast.

I suppose you can always say it is "too slow for my liking" but honestly, Lua in general is very fast, considering it is a scripting language.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

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.

71,863 views.

This is page 2, subject is 2 pages long: 1 2

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

Go to topic: Search the forum

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.