Update is slow.

maslack0 · Post by **maslack0** » Fri Jan 16, 2009 8:02 pm

Hi!

I have been a registered user of Zeus editor since version 3.95y.
The other day, my working version decided it did not like to open files
anymore. I suspect a bad spot on the disk trashed something in the C++
Redistributable package. I do not recall which version this was but
I downloaded the latest version linked to from your website, 3.96r.

The editing screen refresh is very slow now. One can see a wiping action
during page-up and page-down scrolling. On a large file, it is really easy to load up the keyboard buffer so the screen will overrun the desired position while refreshing. Kind of reminds me of my old IBM XT screen and its screen refresh.

An interesting oddity: I also have the old version, 3.95y, that seems to work on this box just fine with quick screen refresh. EXCEPT that the 'line cursor' colors do not work. All I have there is a regular cursor (blinking vertical line).

I really like that line cursor option as I am an older guy, 56yrs, whose sight is a bit compromised.

I suspect that one of the libs Zeus is linked to might be damaged tangled or whatever.

Perhaps I can refresh one of the system libs Zeus requires? I dumped a dependancies on the Zeus 3.96r main executable:

advapi32.dll
comctl32.dll
comdlg32.dll
gdi32.dll
kernel32.dll
msvcr80.dll
ole32.dll
oleaut32.dll
shell32.dll
user32.dll
xnet.dll

And the older Zeus 3.95y main executable:
advapi32.dll
comctl32.dll
comdlg32.dll
gdi32.dll
kernel32.dll
msvcrt.dll
ole32.dll
oleaut32.dll
release/zeus.exe
shell32.dll
user32.dll
xnet.dll

Maybe one that does the colors and screens?

The box is an old Gateway 2000 running Windows 5.1 XP Home SP3, 512 Meg RAM, Intel P4 1.8GHz CPU.
The Microsoft Patches are up to date (today).
This is in a network environment with the Windoze box using mounts from a linux box using SMB/Samba so I can edit in-place php/html files that run under the Apache web server.

Sorry for the lengthy post but I figured it is my box with the problem and I wanted to supply details.

Thanks for any help - I REALLY like this editor!!! A Lot. I don't want to give it up! Wonderful work!!!

Michael.

Post by **jussij** » Sun Jan 18, 2009 11:51 pm

Hi Michael,

The editing screen refresh is very slow now.

Is the screen refresh slow for both small and large files

Maybe one that does the colors and screens?

The Zeus painting code is located in the zeus.exe itself. I'm not convinced this bug is related to a corrupt binary. I myself can't every remember seeing this slow paint behaviour

All I can suggest is making sure the zConfig configuration folder is not corrupted.

To test this I would rename you current Zeus install folder and then re-run the full installer found here: http://www.zeusedit.com/download.html

If this works you can then try to locate the corrupted configuration item by copying back files from your old zConfig folder a few at a time. You will need torestart Zeus each time a file is copied over.

The only other thing I can think of is using the Zeus Macro, Macro/Debug Output menu and checking if there are any error messages getting generated.

This is in a network environment with the Windoze box using mounts from a linux box using SMB/Samba so I can edit in-place php/html files that run under the Apache web server.

Is the slowness only seen in files that are remotely located. Zeus does constantly monitor the status of all the files it has loaded, so this slowdown could be network related

Do you see the same sort of slowdown for local or new files

Cheers Jussi

maslack0 · Post by **maslack0** » Mon Jan 19, 2009 9:40 pm

Is the screen refresh slow for both small and large files?

Not really. Size does not seem to matter.

The only other thing I can think of is using the Zeus Macro, Macro/Debug Output menu and checking if there are any error messages getting generated.

No Errors in this output.

Is the slowness only seen in files that are remotely located. Zeus does constantly monitor the status of all the files it has loaded, so this slowdown could be network related?

Do you see the same sort of slowdown for local or new files?

Both, when a file from the network is loaded.
Here is a log of my observations:

Establish a baseline:
Remove all Zeus apps using 'Add/Remove Programs'.
Remove M$ C++ Redistributable using 'Add/Remove Programs'.
Remove all Zeus directories using cmd.exe rmdir /s .
Clean registry database with Amust 3.5 software.
Reboot Box.
Verify all Zeus apps and the C++ runtime are gone using 'Add/Remove Programs' and the command line.
Login to Linux server and mount my usual directory tree (SMB share).
Install Zeus 3.96r from a fresh archive.
Check network traffic on Linux console: Very little traffic; just ARP queries and SMB KeepAlives.
Observations:
Start Zeus396r and open *local* copies of my work that usually reside on the Linux box (7 files). These files have either a .php, .inc, or a .ini extension. These files vary in length from 4K - 20K
Response is very good. PgUp & PgDn scrolling is smooth as well as vertical and horizontal scrolling.
Open a *local* 2.7 Meg text file without closing the previous 7. Again, scrolling is smooth on both x and y axis.
Check network traffic on Linux console: Very little traffic.
Open the same set of files on the Linux box without closing the local copies.
Check network traffic on Linux console. tcpdump restricted to ports 137-139 and src restricted to the Win box running Zeus: Non stop SMB traffic!

Some timings...
Set focus to a local 2.7meg .txt file on Zeus without keyboard or mouse interrupts: 5.63 pkt/second.
Set focus to a network 2.7meg .txt file on Zeus without keyboard or mouse interrupts: 23.27 pkt/second.
Set focus to a local 2.7.txt file on Zeus with keyboard and mouse interrupts (edit, scroll, mouse events): 199.82 pkt/second.
Set focus to a network 2.7k .txt file on Zeus with keyboard and mouse interrupts (edit, scroll, mouse events): 312.42 pkt/second.

As long as there were network files open, editing was real slow. I also created a new file on both the network and local and in the case where there were other network files open
I got the same slow results.

Other applications that open files on this same server do not behave in this way - The only significant traffic that the server sees is when I save,
open, or close a file.

Anything else I can do, just ask. Hope this helps.

- M -

Post by **jussij** » Mon Jan 19, 2009 11:23 pm

It definitely looks like a Zeus/Network/Samba related issue

As I said earlier, Zeus checks the status of all open files once every quarter of a second and I suspect it is this check that is causing the issue.

My guess is the latest Zeus version is not working because it is using the newer version 8.0 of the MSCRT runtime DLL

To test this you would need to install an older version of Zeus. Unfortunately there is no link to an older Zeus version on the Zeus web page but I did manage to find an older version on the net.

To test my theory could go to the following page: http://www.topdownloads.net/software/ze ... 02937.html

and download the 3.96d version of Zeus.

The download link is a bit obscure. Ignore the big download button, but instead look for the small download link (middle left) that looks like this:

Zeus for Windows 3.96d
Download Now

I download this zip file and ran the installer and checked to make sure that this version does not in fact use the version 8.0 of the MSCRT.

So if this version works fine then I guess that will suggest that the CRT is probably the culprit.

Cheers Jussi

maslack0 · Post by **maslack0** » Tue Jan 20, 2009 9:46 pm

I dl'd the 3.96d version and installed after removing the previous installation as above. The speed was much better; but an oddity: The 'line cursor' color did not work. I would probably blame my box for this.

The SMB packet rate was +- 17 pkt/sec with a network file open and no interrupts (events).

jussij wrote:It definitely looks like a Zeus/Network/Samba related issue :(

Probably nothing insurmountable ;-)

As I said earlier, Zeus checks the status of all open files once every quarter of a second and I suspect it is this check that is causing the issue.

Why??? Thats a LOT of traffic on the wire. Get about a half dozen boxen running Zeus on the wire and things would slow to a crawl.

Hope this was helpful.

- M -

Post by **jussij** » Tue Jan 20, 2009 11:21 pm

Hi Michael,

The SMB packet rate was +- 17 pkt/sec with a network file open and no interrupts (events).

I've never really got into then inner workings of networks but isn't 17 pkt/sec a very low traffic rate

I am only guessing but I don't think the problem is packet related, but probably more to do with timeouts (i.e. SAMBA and Micrsoft not getting on?)

My reasoning is this part of the Zeus code has not changed in decades. The only thing that has changed is the MSVCRT C Library.

Why???

Zeus needs to detect when a file is changed externally by another application or if the file is deleted or renamed.

Thats a LOT of traffic on the wire. Get about a half dozen boxen running Zeus on the wire and things would slow to a crawl.

The load on the network should be next to nothing. The code is doing nothing more than a chmod and an access C Library call for each file that is open, once every quater of a second.

The same code has been in Zeus since the days of Windows 3.x running on 8086 computers with 10 megs of RAM and I have never seen this type of slow down, even when working with network files

This once every quarter of a second check should be blazingly fast on todays modern computers and networks. 250 milliseconds is an eternity on a todays giga hertz machines.

Cheers Jussi

PS: You can install multiple copies of Zeus on the same machine provided they are in their own directory. They will not run into each other.

maslack0 · Post by **maslack0** » Wed Jan 21, 2009 7:16 pm

Hi Jussi,

I've never really got into then inner workings of networks but isn't 17 pkt/sec a very low traffic rate?

A good 'rule of thumb' would be to talk on the network as little as possable. I think I am in good company here... Google 'chatty applications' (not my term) and check out the results.
Microsoft has an opinion on this as well:
http://msdn.microsoft.com/en-us/library ... S.85).aspx

I am only guessing but I don't think the problem is packet related, but probably more to do with timeouts (i.e. SAMBA and Micrsoft not getting on?)

Plausable observation. I set up a test with another Win box (XP Pro) and set up a R/W share between my main box and the XP Pro. Same behaviour.
The Linux/Samba box was shut down.

My reasoning is this part of the Zeus code has not changed in decades. The only thing that has changed is the MSVCRT C Library.

I can relate to that! Don't fix it if it ain't broke!

Zeus needs to detect when a file is changed externally by another application or if the file is deleted or renamed.

Of course! How does Zeus actually flag the user that a file HAS been changed externally by another application or if the file is deleted or renamed.
I set up Zeus396r on the XP Pro box as above opened a file on my main box and used another editor (NoteTab Pro) to change a file that Zeus396r had open on the other box.
I saw no popup dialogs, nothing in the status bar, not much of anything. I then decided to be completely rude and actually delete this same file.
Zeus396r then decided to get mad and flag this file that was loaded as Read Only when attempting to save it to the same shared directory.
Go figure. Restoring the file allowed me to regain R/W access. Go figure...

I can see where my situation is a bit unusual. Most of your customers/programmers would probably check out a project from the server (if a server is actually used.) and bring the project to the local machine to work on.
This way when it is time to turn the crank (do the build), the process would be much faster. Building a project across a network is slow regardless of the network topology.

The same code has been in Zeus since the days of Windows 3.x running on 8086 computers with 10 megs of RAM and I have never seen this type of slow down, even when working with network files

At the risk of sounding trite, the 8086 can address only 1 megabyte of memory. Maybe you mean 80386. I get your point, however.

This once every quarter of a second check should be blazingly fast on todays modern computers and networks. 250 milliseconds is an eternity on a todays giga hertz machines.

But the network interface is the bottleneck. I would sumrise that most folks have 100mb ethernet, some with gigabit ethernet, and, a few out there with only 10mb ethernet.

If you want to persue this network thing, you might grab a freebie called Wireshark, http://www.wireshark.com, and check out the network conversations. It does a nice translation from gibberish to many of the well known protocols such a SMB.
As an aside, the above NoteTab editor is network aware. It will complain if another application changes a document that it is currently editing. It does this without constant polling and signals the change when it gets the focus or when you go to save the work. It gives you the option of reloading or saving the existing document under a different filename.

Sorry I cannot be of further help. I usually don't like to complain without offering a solution to the problem.

Take care...

- M -

Post by **jussij** » Thu Jan 22, 2009 12:27 am

Hi Michael,

Plausable observation. I set up a test with another Win box (XP Pro) and set up a R/W share between my main box and the XP Pro. Same behaviour. The Linux/Samba box was shut down.

Am I reading you correctly when I say you are now seeing the bug on a Windows machine talking to a Windows server

Well that is very strange

Do you have a mapped network drive or are you using UNC names

Do you see the same behaviour if you open the file as a UNC

As a test dragged and dropped 90 text files into Zeus from a network server folder location. The files varyied in size from 1 kBytes to 24 kBytes.

For me I could not see any difference in the speed of the page up, page down, line up, line down, cursor left, cursor right cursor movement.

The painting speed was as fast as always and I could type in new text just as if the file was local

The only slow down that I noticed was that closing a file took about a quarter of a second and it just felt a little bit slower.

Of course! How does Zeus actually flag the user that a file HAS been changed externally by another application or if the file is deleted or renamed.

Inside of Zeus there is a FileStatus that handles this. Below is a the snippet of code that does the checking:

Code: Select all

//---------------------------------------------------------------------------
bool FileStatus::lockedCheck()
{
  //-- check if the we have a file name
  if (szFileName.length())
  {
    //-- check the write access
    fIsLocked = (iFileAccess(szFileName, 2) == 0) ? 0 : 1;
  }

  return fIsLocked;
}

This method does nothing more than call the iFileAccess function which is basically a glorified access function as can be seen from the code below:

Code: Select all

//---------------------------------------------------------------------------
int iFileAccess(const char *pszFileName, int sMode)
{
  int sResult;

  //-- do a simple test first
  if ((pszFileName == 0) || (strlen(pszFileName) == 0)) return ENOFILE;

  if ((pszFileName[0] == '.') && (pszFileName[1] == '\0'))
  {
    //-- fix the bug for when the '.' directory is returned as a valid file
    sResult = 0;
  }
  else if ((pszFileName[0] == '.') && (pszFileName[1] == '.') && (pszFileName[2] == '\0'))
  {
    //-- fix the bug for when the '..' directory is returned as a valid file
    sResult = 0;
  }

  //-- if this is a URL then assume we have access
  if (iFileIsURL(pszFileName)) return 0;

  //-- see if this is a UNC type of name
  if (iFileIsUNC(pszFileName, strlen(pszFileName)))
  {
    OFSTRUCT OfStruct;

    //-- prepare the structure for use
    OfStruct.cBytes = sizeof(OfStruct);

    //-- the standard library does not yet support UNC files
    sResult = (OpenFile(pszFileName, &OfStruct, OF_EXIST) == HFILE_ERROR) ? 1 : 0;
  }
  else
  {
    //-- check for the troublesome A: floppy disk
    if ((pszFileName) && (strlen(pszFileName) > 2) && (toupper(pszFileName[0] == 'A')))
    {
      char szDisk[5];

      szDisk[0] = pszFileName[0];  // A
      szDisk[1] = pszFileName[1];  // :
      szDisk[2] = pszFileName[2];  // slash
      szDisk[3] = 0;

      //-- get the disk type information
      int sDriveType = GetDriveType(szDisk);

      //-- look for the problem child removable disks
      if (sDriveType == DRIVE_REMOVABLE)
      {
        //-- check if the disk is present
        if (iDiskCheck(szDisk[0]) == 0) return EACCES;
      }
    }

    //-- NOTE: This will fix the bugs with access and long file names that
    //--       contain a space character.

    //-- make sure it exists
    sResult = access(pszFileName, sMode);
  }

  return sResult;
}
//---------------------------------------------------------------------------

I saw no popup dialogs, nothing in the status bar, not much of anything.

You would have seen the same changes made in NoteTab Pro in the version of the file that Zeus had loaded.

If you want a message box go to the Options, Editor Options menu and in the General section turn off the Auto-reload changed files option.

You should also see a popup message if you had changed the file in Zeus but not saved those changes and then changed and save the same file in NoteTab Pro.

I then decided to be completely rude and actually delete this same file. Zeus396r then decided to get mad and flag this file that was loaded as Read Only when attempting to save it to the same shared directory.

When the file disappears from the drive Zeus will flag this file as R/O.

Zeus won't let you save it (since it no longer exists) but if you really want to save the file you have to use the File, Save As option.

Go figure. Restoring the file allowed me to regain R/W access. Go figure...

In this case Zeus detected that the file was now back so it was once again happy to save the file.

It looks like the like the quarter second Zeus timer tick is working as designed

This way when it is time to turn the crank (do the build), the process would be much faster. Building a project across a network is slow regardless of the network topology.

In all the years I have been developing Zeus there have been many times when I have used it to edit files on remote machines.

In all that time there have also been a about three or four reports of slow Zeus edits of networks files.

I don't doubt that the problem exists but for the life of me, every time I try to access a file over the network I never see a slow down.

At the risk of sounding trite, the 8086 can address only 1 megabyte of memory. Maybe you mean 80386.

You are spot on

But the network interface is the bottleneck. I would sumrise that most folks have 100mb ethernet, some with gigabit ethernet, and, a few out there with only 10mb ethernet.

As I said I don't doubt you are seeing a slow down. The really frustrating thing for me is that no matter how many network file I load into Zeus I can't replicate the slow down at this end

Cheers Jussi

maslack0 · Post by **maslack0** » Thu Jan 22, 2009 7:47 pm

Hey Jussi,

Am I reading you correctly when I say you are now seeing the bug on a Windows machine talking to a Windows server?
Well that is very strange.

That is correct, Windows client to Windows server.

Do you have a mapped network drive or are you using UNC names?

I conducted my tests using mapped drive letters. As soon as you brought this up I went ahead and tested files using
UNC. Same behaviour.

As a test dragged and dropped 90 text files into Zeus from a network server folder location. The files varyied in size from 1 kBytes to 24 kBytes.
For me I could not see any difference in the speed of the page up, page down, line up, line down, cursor left, cursor right cursor movement.
The painting speed was as fast as always and I could type in new text just as if the file was local.
In all that time there have also been a about three or four reports of slow Zeus edits of networks files.
I don't doubt that the problem exists but for the life of me, every time I try to access a file over the network I never see a slow down.
As I said I don't doubt you are seeing a slow down. The really frustrating thing for me is that no matter how many network file I load into Zeus I can't replicate the slow down at this end.

I hear that!!! I used to be a partner in a company that coded up and sold ROM-BIOS replacements/upgrades in the '90s. I did QA and tech support and did I ever get the tough ones (and the kooks).
I checked my LAN adapters on the boxen being used for errors, collisions, and frame errors and these numbers were really low compared to the total number of RX and TX packets. (I rarely turn these boxen off.)
It is obvious that you cannot do anything about this if you cannot replicate the problem.
The problem is probably due to the age of my gear (!bleeding edge) and maybe some DLL hell thrown in just for funzies.
I would love to be able to demo this but I fear that it would be a long walk and a longer swim. (I reside in the central US)
Just a suggestion: You might consider having an option available to users where they can enable/disable 'File Change Polling' and if enabled, have an option to set the poll interval.
I *really* like this editor, though. I will probably just work around the problem. (shell scripts or batch files come to mind.)
Take care,

-M-

Post by **jussij** » Fri Jan 23, 2009 2:49 am

Hi Michael,

In an effort to isolate the issue I create two test executables using MSVC and Visual Studio 2005 found here:

http://www.zeusedit.com/z300/access.zip

These executables do nothing more than check the file status some 100 times and print the results to the screen (the source code and project files has also been included in the zip file).

When I run these excutables the 100 loops takes about 0.3 seconds for a large network file.

The 100 checks completed in a total time of: 0.28200000 secs

Could you try these out on your machine and post back the final time result.

Cheers Jussi

maslack0 · Post by **maslack0** » Fri Jan 23, 2009 7:03 pm

Hey Jussi,

Here's the results:
(moo is my main box, dev is the box running XP Pro, and darwin is the Linux/Samba box.)

Moo is running just the cmd.exe shell, dev is running nothing but the normal XP-Pro services. Darwin is
running as it normally boots, apache2/php, mysql, smb daemons, and the regular stuff that make it run properly.
The webserver and mysql were idle, the smbd daemons were not.
I used a batchfile to create logfiles using stdout redirection (>>).
Text file size is 2.8meg.

moo to darwin (access.exe):
The 100 checks completed in a total time of: 0.18000000 secs
The 100 checks completed in a total time of: 0.17000000 secs
The 100 checks completed in a total time of: 0.17000000 secs
The 100 checks completed in a total time of: 0.17100000 secs
moo to dev (access.exe):
The 100 checks completed in a total time of: 0.14000000 secs
The 100 checks completed in a total time of: 0.13000000 secs
The 100 checks completed in a total time of: 0.12000000 secs
The 100 checks completed in a total time of: 0.13100000 secs
moo to darwin (access-2005.exe):
The 100 checks completed in a total time of: 0.17000000 secs
The 100 checks completed in a total time of: 0.17000000 secs
The 100 checks completed in a total time of: 0.17000000 secs
The 100 checks completed in a total time of: 0.17100000 secs
moo to dev (access-2005.exe):
The 100 checks completed in a total time of: 0.13000000 secs
The 100 checks completed in a total time of: 0.13000000 secs
The 100 checks completed in a total time of: 0.13000000 secs
The 100 checks completed in a total time of: 0.13000000 secs

I also ran Zeus396r on moo, dev and an identical box to moo with the same open files on darwin. (Dumb but wanted to
keep things identical.)
The timings were a touch slower but not that much. The machines were idle as I am the only here, but Zeus had
the focus in all cases except moo where I had to exec the batchfile that ran the tests.

I can email you the full results plus a description of my LAN topology to your info address if you wish.

-M-

Post by **jussij** » Sat Jan 24, 2009 1:03 am

That is not what I expected. Your network can check the access faster than mine

So it looks like the slow down is not comming from the file access checking

This has me a bit confused since other than opening and closing a file I can't think of any other time when Zeus goes to the network

Cheers Jussi

maslack0 · Post by **maslack0** » Sat Jan 24, 2009 5:45 pm

Hey Jussi,

That is not what I expected. Your network can check the access faster than mine.

I saw that... Hmmm.

So it looks like the slow down is not comming from the file access checking.

It is probably my older machine that is getting stacked up by the network polling. On the XP Pro box
(Celeron 2.4ghz w/ 768 meg RAM) it runs a bit smoother but still clunky. I don't much care for that box because the
mainboard design is probably a cheapie and it acts like it is I/O bound on everything. (it was a turn-on, hey...)

This has me a bit confused since other than opening and closing a file I can't think of any other time when Zeus goes to the network.

I would be glad to try out a version that has polling either disabled, an option in one of the config menus as above,
or even a command line switch. It would be worth a try in my humble opinion.

Take care,

-M-

Post by **jussij** » Sun Jan 25, 2009 5:43 am

I would be glad to try out a version that has polling either disabled, an option in one of the config menus as above,
or even a command line switch. It would be worth a try in my humble opinion.

I had a look at the timer code and it turns out it already self regulates. It does a check where by if the timer takes too long to complete it increases the timer period. So I am pretty sure the timer is not the problem. But I think I might have found the problem

I found a piece of common code used extensively throughout the program and it contained a few lines of code that did a directory check. I think it is this directory checking that is causing the excessive network traffic.

I will create a beta version without this checking to see if it speeds things up

Cheers Jussi

maslack0 · Post by **maslack0** » Mon Jan 26, 2009 11:23 pm

Hey Jussi,

It went well!

The response time, refresh, etc, ad nausium, are all cleared up.
Not as much traffic on the wire, either.

I will post if I encounter any problems...

-M-