Another D3 pointer that I missed… Here is one of my own quotes from CDP:
I’ve had recent experience with apps that have so many errors during the course of the business day that the RUNTIME-ERRORS file itself gets very fragmented, and every update results in delays as the system chases frames into overflow. Identify your errors, fix them, then delete the file. If you suspect more errors, recreate the file with a mod of something like 101 and wait for more errors to get logged.

The experience mentioned was with a DesignBais site: v3.3 has some Variable Not Assigned and other errors that are emitted from BAWEBEXEC at runtime. These errors don’t mess up normal data exchanges but DBI is cleaning them up for v4 anyway. If the runtime-errors file exists in dm, normal DB usage will start to have an impact on this file.

And yet another pointer on performance: mv.NET uses a feature called Character Conversion to ensure that 8-bit data is transmitted reliably between clients and their 7-bit DBMS hosts. For NT systems it’s "probably " OK if no character conversion is done, so all transmissions are in 7-bit. For *nix systems there is usually full conversion. This soft conversion process can have a moderate impact on performance: every character needs to be checked to see if it’s an 8-bit char that needs to be split into two 7-bit chunks. Turning on character conversion is often necessary, but if you don’t need it, absolutely turn it off.

Since we’re here, in D3 once in a while I see lists in the pointer-file too but they don’t usually accumulate. Sample ID’s:
   331.14042.718118543.250
   331.14092.190849421.83745
   331.14092.713154933.65307
The second field is the internal date, so you know when the items are old.

I will update this article after v4 is out, and also when I get more details about how DesignBais works with jBASE, OpenInsight, OpenQM, Reality, and whatever other platforms they support.