This appears it will be very relevant - specifically the SQLLite and tight loop optimizations:
=============== EDIT
I updated my Full Node (and harvester) to the 2.1.4 release and the Full Node behavior is quite different now. Previously the full node process was pegged at 100% CPU, now it is sporadic and the load average is around 0.4. Previously on 2.1.3, this had tended to go up over time until the CPU was saturated, so I’ll withhold full judgement until some time passes and the load stabilizes, but this appears to be different and vastly improved behavior in 2.1.4 vs 2.1.3.
Another note - I’ve been having stale processes left over after doing a chia stop all -d, one or more of which were holding locks that prevented a restart. This might also be pointing to a bug in the previous code WRT stuck transactions (deadlock) or other potential issues. Hopefully this update also tackled some of that.
BTW - here is the change they made to the Full Node code that fixed-ish the spinning problem: Spin slower `send_transaction()` by arvidn · Pull Request #17166 · Chia-Network/chia-blockchain · GitHub. They changed the sleep period from 10ms to 500ms. This doesn’t really change how this works - it’s a tight loop with polling layered over a SQLLite locking layer to manage their mempool - seems like this needs to be replaced in order to enable multi-processing.
I posted a question to the maintainers to see if they’re open to changing the multi-processing of the event loop in the Chia Full Node code to make it more responsive on lower end CPUs. Note that at this time, on modern-ish CPUs, the Full Node code is near full capacity, so it might actually be a necessary modification if the network traffic increases from here.
=============== /EDIT