Abnormal time to open World Properties

I'm not sure why, but it takes an abnormal amount of time to open World Properties.

It takes about 7 seconds to open World Properties. I just closed MUSHclient and re-opened it, and it still takes that long. My computer isn't slow or anything. It has a gig of RAM, 2.66 GHz, etc. I don't think it should take this long to open. Any world will take this long to open. Any ideas why?

This has just started happening I presume?

Which version are you using?

Which properties window is it opening first? The one with the IP address on it or something else?

Do you have lots of triggers/aliases etc?

This has actually been happening for a while.

I was using 4.12 and then I updated to 4.16 today. The problem still exists.

Any properties window will do this. Triggers, IP, etc.

I have no triggers or anything. Maybe just one to save every 5min.

The problem is that MUSHclient freezes during this time. I have multiple windows open, and sometimes 7 seconds can easily mean life or death.

This sounds a bit like this that I reported:

http://www.gammon.com.au/forum/?id=7750

However that was closing, not opening.

Most of the world property windows use "lazy opening" - that is, the particular page doesn't load all its stuff until you switch to it. For example, the triggers list, I think, doesn't load up until you view triggers.

I will take a look at what gets loaded up anyway (before the window displays) to see if I can spot something. About the only thing I can think of offhand that might take a few seconds is IP address resolution, which I don't think it even attempts to do.

Failing that I will try to make a version that shows on the status line which page it is loading (the values for), so you can try to see where the problem is.

Hm, well for the world I use an IP and not a domain if that matters.

Do you have heaps of lines in your output buffers when this happens? Maybe it is a paging issue?

Nope, like I said I tried it right when I re-opened MUSHclient. I had a total of maybe 500 output lines in all worlds.

OK, then. Please download this version:

http://www.gammon.com.au/files/mushclient/mushclient417.exe

Then using Lua set the config debug on:


utils.showdebugstatus ()


You could put that line into the Lua sandbox, or just execute it from the command line.

Then try opening the config. A whole heap of messages should flash by on the status line (too fast to read in my case). However if one sits there for a few seconds, please tell me what it is.

All I see in the status line after doing that is:
World config - showing dialog
Ready

But after Ready appears, it's still about 5 seconds before World Properties even appears.

Sigh. At least I know what it *isn't* now.

Let me take another look.

Do you have a script that runs on getting/losing the focus?

And, does it happen if scripting is disabled?

I don't have any scripts in any worlds.

Turning off scripting does not fix it either. But it does change the status bar, I think.

It now says "World config - showing dialog" the entire time, instead of showing Ready most of the time.

So it says "World config - showing dialog", and then there is a lengthy delay before the dialog appears?

Right. While that text is being shown, the World Properties is not yet loaded. Then once it loads about 7 seconds later, the status bar changes to Ready.

During that 7 seconds is the CPU usage of MUSHclient maxed out?

Nope, it gets to around 25%.

If you press <ESC> during the 7 seconds does that close the window? In other words, is it there but invisible, or is it not there at all?

How many CPUs do you have? 25% sounds a lot. If you have 4 CPUs that is 100% CPU on one of them.

Yes. If I hit Esc during the 7 seconds, the window will later load at the time (7 seconds) and then immediately close.

The delay appears to be somewhere in the bowels of MFC, which makes it hard to find. I am wondering why it only seems to happen to you, unless everyone is getting a 7-second delay and thinks that is normal somehow.

My current guesses are:

• Something to do with multiple CPUs. The delay I get sometimes on closing the configuration dialog occurs on my newer PC, which is a PC with 2 CPUs. I never get it on my single-CPU PC.
  
• Something to do with the new Internationalization stuff (boy that word is hard to type!). Try an earlier version that didn't have it (eg. 4.02 or something). Maybe reading the resource file DLL is slowing it down.
  
• A virus-checker is checking access to the EN.DLL file. Try turning virus checking off for a minute and seeing if that helps.
  
• You have installed a debugger that is intercepting some debugging internal messages perhaps. Have you installed anything just prior to this problem happening?
  
• Is there something else a bit non-standard? Like, using multiple monitors?

This computer only has one core.

How would I install an older version without overwriting the current MC registry?

Turning off my virus detector didn't help.

This has been happening for a while. I can't think of any debuggers I installed. I normally keep my compilers (Visual Studio etc) on my laptop, and not this desktop.

Nope, normal desktop. One monitor. One core. 32bit. Etc.

I have created MUSHclient Live that you place in the same directory as the version that you want to run, it backs up ANY current MUSHclient settings, and runs from the settings that is located in the same folder, then upon closing it will restore the pre-existing settings, if any...

www.torasin.com/~venificius/MUSHclient_Live.exe

I posted this a while back so that you could run MUSHclient on a removable media of most kinds.

Hope that might help you in this way.

Laterzzz,
Onoitsu2

It shouldn't matter too much to revert to an earlier version. You could copy the entire MC directory to MC.bu or something like that, to keep everything, and then just do an install of an earlier version on top of the existing one. Then just copy the directory back when you have finished.

Or, you could just use Regedit, and rename:


HKEY_CURRENT_USER\Software\Gammon Software Solutions\MUSHclient


to, say:


HKEY_CURRENT_USER\Software\Gammon Software Solutions\MUSHclient.orig


Do your install, test it, then rename the registry key back. Shouldn't really have to do that. Or use Regedit to export that key tree, and keep for later importing if necessary.

You got MUSHclient to compile yourself, right Zeno?

How about doing a compilation of a recent version (debug compile), then running in debug mode (I hit F5 to do that). Then when the big delay comes up, quickly switch back to Visual Studio and hit Break (Ctrl+Break I think). That should interrupt it, and you should be able to see where in the source the delay is.

I just tried that.


If I try to break normally (like in the menu), it'll bring up source code.

When it breaks, can you use the "Context" debug combo-box to work out further back in the call chain where it is?

I'm not sure what you're referring to. I don't see a "Context" window either.

I am referring to this, which I see when running in Debug mode (start debugging with Build Menu -> Start Debug -> Go):

Yeah, I don't see that. Maybe the newer versions renamed or removed it. I have the following windows/tabs open while debugging: Solution Explorer, Autos, Locals, Watch 1, Call Stack, Breakpoints, Command Window, Output and the main code window.

It may be Call Stack. But the only thing in that window is:

It will be Call Stack, same thing.

I was afraid you would get that. It looks like it is inside the NT Kernel somewhere. Sometimes I get that in the call stack when I interrupt the program.

I *think* you can run something that installs the Kernel debug symbols, it comes with the Visual C++. If you can hunt that down, it may give you the symbol names for those places in the Kernel, which may or may not help.

Unfortunately we aren't getting very far. It is hard to know the significance of what you are seeing, and why it only happens to you.

No need to rush. I bought a new computer. ;)

I may replace my old server with the computer I just replaced, so this problem may be gone soon enough.