Fox seems to store strings internally in some non-contiguous fashion - perhaps as a list of fragment buffers, who knows. One tell-tale symptom is that LEN() takes considerably longer to return a result for very long strings than it does for short ones (the increase is non-linear).

The net effect is that string handling becomes rather inefficient when string size goes beyond 10..100 KBytes and operations involving very large strings (MByte-ish) can take several seconds; I have found the breakeven point performance-wise for using low-level file functions or memory buffers (via SYS(2600)) instead of strings to be somewhere between 10..100 KBytes.

Also, calls to DLL/FLL functions involving strings tend to perform poorly compared to functions that take only numeric parameters - apparently the strings must be 'flattened' from their internal representation to the contiguous layout expected by the external functions.

The OCCURS() function is a good example for the performance trade-off between C++ and Fox. For general programming C++ is several orders of magnitude faster than Fox but for the example problem you'd say

? occurs("Anna", filetostr("book.txt"))

and have an answer before the C++ folks are even done coding. I like both languages immensely but I use Fox much more than C++, because in most cases Fox is fast enough to solve a problem (especially when one can let Fox do most of the work via builtin functions like in this example). When I need crunching power (image processing etc.) then I often try Delphi first - it is at least an order of magnitude slower than C++ but one can get simple stuff done faster in Delphi than in C++.