>I'm updating ExcelListener.vcx to take advantage of Greg Green's excellent class vfpxWorkbookXlsx.vcx, which creates Excel files with xlsx format.
>
>To optimize speed I want to make sure cursors remain in memory only. I believe this is the default VFP behavior, but am confused by the fact that you can append from a cursor by referring to it as DBF('CursorName') and the fact that that that file actually exists on disk.
>
>I'd appreciate any clarifications. No need for ram disks, right?

Small cursors on systems with lots of RAM may never hit the disk. I just did a little ad-hoc testing in a VM with 8GB RAM. Created a tiny cursor, got its "temp file" name, looked for it in File Explorer (does not exist), tried opening it from another VFP instance (file does not exist). Created another cursor in the first VFP instance, appended from 1st cursor - neither cursor shows up in File Explorer or can be seen from the other VFP instance.

So at least some operations with small cursors don't hit the file system at all (unless it's something we can't see like getting a file handle). VFP must be using its internal buffers to store the cursor contents and buffer or emulate NetBIOS calls.

Large cursors may be a different story. The first stop is SYS( 3050 ). In my VM with default settings:

- SYS( 3050, 1 ) = 2,943,090,688
- SYS( 3050, 2 ) = 735,838,208

According to reports on the Fox Wiki http://fox.wikis.com/wc.dll?Wiki~sys3050~WIN_COM_API having either of those buffer settings over 512MB may be detrimental to performance. I'm not sure how a 32-bit app that has a safe address space of 2GB can even access or manage 2.9GB nominal buffer space if it tries to allocate the maximum. Maybe there's a hard upper limit on SYS( 3050, 1 ).

So, on systems with lots of RAM you may not hit the file system at all until cursors + working/temp space exceeds 512MB (Wiki recommendation) or maybe close to 2GB if you let VFP claim as much as it can.

If you go beyond that you first hit the Windows system file cache: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364218(v=vs.85).aspx . Write operations are something of a special case - for desktop systems write caching is turned off by default (write-through mode)(slower but safer in case of power outages etc). My systems have UPSs and I turn write caching on (write-back mode). If you overwhelm VFP's buffers and VFP has to write to disk, and write caching is disabled, then your app will wait for an actual disk write to complete. In contrast, if you enable write caching then the effect is basically the same as a RAM disk - but for the entire computer, not just hogged by your app. Other apps or services can get out of your way quicker and respond faster to requests your app may make.

If write caching is off, or you overwhelm the write cache then your app's responsiveness depends on the persistent storage subsystem. If it's a basic desktop computer then it may have a single magnetic SATA drive with just a buffer. That buffer might be 64, 128 or more MB but if you've overwhelmed a VFP buffer setting of hundreds of MB and possibly a Windows write cache of multiple GB then that small buffer will likely also be immediately overwhelmed as well, so you'll be crawling at magnetic HD speed. If the persistent store is more exotic then performance will be better, but never as good as local RAM.

Lots of thinking out loud there but my gut feel is you're probably never going to need a RAM disk in real life. You'd have to overwhelm the VFP buffer settings as well as the Windows disk cache if you enable write caching. What I'd do, in order:

- Check and experiment with SYS( 3050 ) settings and compare to your cursor sizes
- Consider enabling write caching in Windows