>I'm pretty sure Fox was always faster than dBase. :)

I do recall noting with a few tests that we exclude any operations on tables and only looked at how fast looping, arithmetic and string operations could be performed, dBase III+ ran at about 1/4~1/3 the speed of equivalent BASICA/GWBASIC code (this seemed to give the indication that dBASE might not "running" a tokenized representation of code but perhaps re-parsing the ASCII representation). That being said Quicksilver claimed to get up to 2x or 3x speed performance over dBASE III+ (after optimization) -- which probably isn't saying much IMHO. I do recall when I first puttered around with FoxBASE, I'd noticed the speed was at least as good (if not better) than I was seeing with stuff compiled with Quicksilver. We ended up switching to FoxPro after dealing with performance issues under Quicksilver -- the switch to FoxPro alone yielded an automatic performance boost. We never tried out Quicksilver Arago, which arrived a bit late in the scene. Aside from the relatively poor performance of Quicksilver code, the other factor in moving away from Quicksilver was annoyance of its implementation -- the "compiled" version of PRGs used the same PRG extension (rather than using a different extension) and to differentiate the "compiled" copy, it prepended a leading character (can't recall if it was a tilde or @ symbol) -- meaning we had to keep filenames unique to 7 characters. Aside from these, the better screen management implementation meant we could toss out a lot of code we had for screen management (e.g. binary code we were to take "snapshot" of video memory and restore it, code for partial and complete redraw of screen to simulate windowed display, etc.), whilst gaining ability such as mouse interaction and movable windows. I was able to keep much of the code I'd already written for communicating over the serial port (which is what I was originally hired to do -- write interface code to communicate with some devices connected to serial port).
The switch from FoxPro DOS to FoxPro Windows did require me to rewrite some amount of code that I'd written -- mostly due to very different API for communicating through serial ports. Similarly switch from FoxPro Windows to Visual FoxPro required another rewrite as well (due to differences in Win16 and Win32 API for handling serial ports) -- though leveraging the OOP orientation did simplify the task somewhat.