Foxpro slow using files

[mrc2048]

Hi

I have a menu driven foxprox application that closes all data files while the users is on the menu.  When a user chooses a program from the menu the first thing the program does is open or "use" the files it needs.  I have found by tracing that that step is taking significantly longer in vDos than NTDVM.  Once the files are in use or open the performance is excellent.    All of the data files are on a network shared drive. and I have already thought of variations on leaving the files open at the menu but there still will be a performance hit or too many files open simultaneously not to mention the risk of data corruption.

Can you see why the foxpro "use" command would perform so slowly when everything else seems to run fine?

Thanks

[Jos]

The only thing that comes to mind is vDos going to idle mode too soon. With disk operations vDos should operate at peak performance for some amount of instructions. Not time, since the disk response can be fast (local), or relatively slow (network). The current vDos version has the mishap the set amount of instructions being a factor of 40 off, thereby going idle far too soon. You can eventually check by starting vDos with the log option (“…\vDos.exe” /log). Open the generated vDos.log file just before selecting the menu option, it will probably show vDos is in idle mode. Then select the menu item, and re-open vDos.log. vDos should have kicked in again, with only one “Idle end” (and eventually “Idle”) entry added during the period the program performed the “use” sequence. If there’re more, vDos went idle between the “use” operations, so slowing that process down.

Leaving files open shouldn’t be risky, but it sure doesn’t feel right. If you have the mouse enabled (MOUSE = ON in config.txt), and you can do without, consider/try to disable it. FoxPro programs massively (up to several thousand times per second) call the mouse driver. FoxProX has to drop out of protected mode, call the driver, then engage protected mode again. That involves a lot more for FoxProX than a mere turn of a switch. All these calls with lots of instructions could well cause vDos to go idle premature during the “use” sequences. There’s no 16 bit mouse driver in vDos, so the next version will trap FoxProX mouse inquiries, and shortcut FoxProX code dealing with the mouse. That’s also one of the reasons FoxProX programs will run noticeably faster.

Jos

[mrc2048]

Sorry for the delay in responding. 

There has been an increase in the number of users running vDos so the problem has been brought to my attention again.

I did follow your suggestion and disabled the mouse but that did not help.

As I said before the problem is in foxprox v2.6 and just in the amount of time it takes to open (use) the files that are on a network drive.  When I run the same program on the server that hosts the shared drive the performance opening (using) the files is great.  Once the files are open the rest of the program runs great even when the files are on a shared drive.  This is theonly issue we have - all in all it runs better the NTVDM.

Have you found anything that might help since I last posted?

Thanks

[Jos]

Did you meanwhile switch to the latest (2019.05.01) version of vDos?
FoxProX mouse inquiries have a shortcut, It doesn’t actually call (unneeded) mouse functions and so mostly (99+%) won’t go out of and back into protected mode anymore. vDos going idle premature is fixed.
Essentially there should be no reason FoxProX USE taking more time in vDos than in NTVDM. Even using remote files shouldn’t matter, a bare file open operation involves little network traffic.

Jos

[mrc2048]

I am on the latest version (2019.05.01) of vDos. I turned the mouse back on its no worse so that's good.

If I turn tracing on in the foxpro application I can see it pauses while trying to use the files on the shared remote drive.

Is there anyway I can trace at a lower level to see what's taking so long?

[Jos]

You could try this:

Start vDos with the log option (“…vDos.exe /log”).

A vDos.log file will be created in the vDos directory.
That mainly reports exceptions, so it could very well miss what causes the delay with FoxPro USE.
Open the vDos.log file (for instance with Notepad) when you are in the menu, so before the USE’s are executed.
Then select a menu option causing a delay.
Update vDos.log in the editor, if there are actual new entries, post those.

To keeping a file open: That doesn’t make the file in anyway vulnerable. Even the opposite: Depending on how the file was opened, it can’t be deleted or even modified (opened exclusively) while it’s still open by a Windows instance.

Jos