Thanks Thomas,

These are all great bits of information.

>Hi Al,
>
>I am all the way with you that trying to outsmart processor affinity compared to automatic OS handling will probably be utile and perhaps might even degrade app performance.
>
>I'd probably be a nastier devils advocate than your hinted
>>- Ask them for expected benefits and expected degradation of other processes
>>- Ask them for detailed technical background to show they understand why the process will benefit.
>>- Make sure YOU understand the reasons they give and can accept the drawbacks
>
>OTOH,
>>That said, I doubt anyone would see much benefit doing this for a VFP app on a modern Windows system.
>
>might create false impression - at least for some clearly defined edge cases.
>Are there potential benefits ? Yes, CPU and context switching incur lags, esp. when caches are flushed or "other" caches are accessed, causing a fill.
>
>Also vfp being single threaded for most aspects of running user code IMO makes it a better fit for such operations than a modern exe utilizing many threads, asynch or parallel processing.
>
>If CPU has ample cores for every background task and CPU of vfp process is maxxed, such action could yield benefit. You would need to restrict all other tasks to a pool without "reserved cores", perhaps assign every accessed process (think AV or FW) separate pool or dedicated core(s), and let vfp run full blast on a dedicated core, you might eek out few single digit % perf benefit. Doing it via GUI is a no-no, do it up front via API for all running processes.
>
>If CPU and OS support elevating single core frequency, even more tests are needed - forcing minimal background activity on "other" cores might cut turbo-frequency.
>
>That said, I am certain a comparable effort (hourwise) in optimizing the app source code or distribute work lode over multiple threads or processes will get a much larger benefit in performance. If no source is available, just buying faster HW probably will also get more bang for the buck.
>
>regards
>thomas
>
>>>Is there a way you can bind an executable to a particular CPU core?
>>https://en.wikipedia.org/wiki/Processor_affinity
>>
>>Assuming you're talking about Windows, NT and successors support this:
>>https://winbuzzer.com/2020/07/03/how-to-set-cpu-affinity-in-windows-10-with-task-manager-or-system-properties-xcxwbt/
>>
>>That said, I doubt anyone would see much benefit doing this for a VFP app on a modern Windows system. Bear in mind doing this reduces the flexibility of the Windows scheduler - it can no longer fully optimize resource usage amongst all competing processes. If setting affinity for one process improves its performance by X%, the performance of all other processes will probably be reduced by (some multiple of) X%.
>>
>>These days CPU is rarely a performance bottleneck. If you need more overall performance you'll probably see greater gains by improving disk, RAM or network.
>>
>>I've read that some enterprise loads such as SQL Server and Exchange can benefit from it, especially on multi-processor/NUMA hardware e.g. https://infohub.delltechnologies.com/l/performance-best-practices-3/sql-server-2019-cpu-affinity . Getting those techniques to actually work as expected is enterprise-grade stuff.
>>
>>If someone is asking you to set CPU affinity for a regular business-type application I'd suggest:
>>
>>- Ask them for expected benefits and expected degradation of other processes
>>- Ask them for detailed technical background to show they understand why the process will benefit. Basically, explain how setting affinity for that process will be better than the default scheduler behaviour
>>- Make sure YOU understand the reasons they give and can accept the drawbacks
>>
>>Be aware that setting affinity won't work well, or at all, in a virtualized environment unless the hypervisor will accept hints from guest OSs (and abide by them). That sort of paravirtualization support is not a given. If not in place the hypervisor will manage its vCPUs however it sees fit, regardless of what guest OSs think they're doing.