>>>Therefore I think disk speed might play a role comparing both approaches, even if as here maybe only a part of table will be copied - a vfp cursor often does not need to write if filter is simple enough and filling the clipboard from there could be faster than the explicit copy to, filetostr() dance needed for concat and single paste ;-)
>>
>>Not sure how disk speed should factor into this... I for one have a UPS and configure disk caching of writes as aggressively as possible. As long as the cache isn't overwhelmed, it should be way faster than any SSD.
>
>You are right, it doesn't make much difference. With regular 7200 RPM disks it were taking 0.82 - 0.89 seconds. I tried with SSD (Samsung 850 EVO) and took 0.77-0.79 seconds. -vfp.DataToClip() takes over 9 seconds. Looks like many developers are not aware that DataToClip is very slow itself.

It seems to be one of those pedestrian things, getting squarely slower with size? My sheets used to be some kind of daily reports, never larger than max 2 pages when printed, which is probably the explanation on why it was fast back then (10 years ago, in IIRC VFP8).