>>Also certain that there are probably more more than 2 handful of people with knowledge of those structures: first all the people at MS hacking at the C(++) sources, besides Calvin was Alexey T. who informed me once that one of the bugs I had reported was a wrong type cast in C code, and probably a few others. In Userland besides Chen is Christoph Lange, who knows much more about internal working of vfp compared to me, and most devs creating Flls have some knowledge about vfp variable structures just by reading comments in the sources...
>
>Dang... I had a book (which came with another bunch of books and some 17 floppies in the FP2.5 package) with instructions on how to write fll (though it was called differently then), and it had the memory structures laid out.

and a non-MS compiler was used...

>A VFP variable has some 16 bytes descriptor block, where only the first two integers (32 bit, of course) are pointer and length. The rest describe type and few other things. Dom't ask me how much more I remember, it's very little.

Yupp, IIRC struct with ev_type, ev_value and in ev_value a pointer to strings if not one of the smaller types/so described in ev_type. String pointers had to be given some Handle2Pointer treatment and sometimes memory had to be locked and unlocked - pretty certain because of reshuffling unlocked memory on garbage collection time.

Locking some parts of memory just not to loose pointer access sounds not like a good idea, esp. if result of accessing again seems to result in user interface msg - not really in need of machine code speed. Why not just add another handle in vfp memory or save the object path ?

The real speed benefit in C vs. vfp comes from using statically typed variables, just coding in C and accessing vfp variable space often gains results not worth the added effort. Reserve a whooping amount of memory early on stack or heap and do most of the work there and you can expect a speedup of 3 - 12 times. Calling sub-functions in C-space also highly beneficial.

Did not go into detail when objects were introduced in vfp - read some bits to form the impression that objects were somewhat analogous to data sessions isolating dbfs, using NTI(s) and allowing to use identical names many times. Might explain perf getting a hit with too many objects.

Stayed with simple calls on primitve types - please only think the answer coaxed from that statement ;-)