Zeus IDE

The editing screen refresh is very slow now.

Maybe one that does the colors and screens?

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 screen refresh slow for both small and large files?

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.

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?

jussij wrote: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.

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

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.

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.

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

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.

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.

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.

//---------------------------------------------------------------------------
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;
}

//---------------------------------------------------------------------------
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.

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...

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.

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

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.

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?

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.

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

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.

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.