SUMMARY
kscreenlocker_greet process consumes 100% CPU if it starts up when that user isn't the active user, i.e. that user is not currently using the display. Note that that although this looks similar to bug #347772, it isn't the same bug.

STEPS TO REPRODUCE
1. Have 2 users logged into X
2. In user1's session:
        sleep 5 ; kscreenlocker_greet
3. Immediately switch to user2 with e.g. <ctrl><alt><f8>

OBSERVED RESULT
After 5 seconds, user1's kscreenlocker_greet process starts and immediately consumes 100% CPU. 100% CPU is also used if that user's kscreenlocker_greet process is started automatically by plasma when the idle period expires, provided that I've already switched to another user. This is 100% reproducible for me. If I lock screen manually or run e.g. kscreenlocker_greet --graceTime 5000 then everything is fine.

Although I'm running debian testing (libkscreenlocker5 5.14.5-1), I've also tried downloading the latest source of kscreenlocker/greeter from git.

Adding ProfilerStart()/ProfilerStop() from Google's perf tools around app.exec() in main.cpp of greeter hasn't been very useful as it appears that CPU is being used somewhere in QSGBatchRenderer::Renderer::renderMergedBatch() which seems to be calling _nv023glcore() (somewhere in Nvidia's driver presumably).

I'm assuming the problem is that something is trying to access the display, but can't, because it's being used by another user. However, as this could be quite common in a multi-user setup, perhaps there's something different about the way 
kscreenlocker_greet does it?

EXPECTED RESULT
kscreenlocker_greet should use <1% CPU.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian testing 
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.54.0
Qt Version: 5.11.3
Nvidia drivers: 418.74 

ADDITIONAL INFORMATION
kcachegrind output: http://www.mettalogic.co.uk/tim/tmp/screenlock_cachegrind.png