Some earlier experiments under versions 45 and below had suggested that CPU time was 1-5% less than elapsed time - so if you wanted to delay by 5 secs, the CPU consumed would be somewhere between 4.75 : 4.95 CPU secs
But I retried in V46 using this simple testbed:
Integer delaySecs = 15
Long start = System.currentTimeMillis();
Integer cpuStart = Limits.getCpuTime();
Util.sleep(delaySecs);
Long stop = System.currentTimeMillis();
Integer cpuStop = Limits.getCpuTime();
System.debug(LoggingLevel.INFO,'elapsed delta:' + (stop-start));
System.debug(LoggingLevel.INFO,'cpu delta:' + (cpustop-cpustart));
And got these results (V46)
delaySecs (input) elapsed (result) cpu (result)
18 18.003 10.020 (over limit)
17 17.002 9.304
16 16.003 9.265
15 15.004 8.552
14 14.017 8.001
13 13.002 7.231
...
10 10.003 5.431
...
5 5.020 2.812
4 4.002 2.298
3 3.016 1.724
2 2.016 1.146
1 1.033 0.586
YMMV and there's no guarantee that SFDC won't change the underlying implementation of System.currentTimeMillis()
to be closer 1:1 with CPU time.
How might this be useful?
- Implementing a variable backoff delay (jitter) in asynchronous queueable transactions that lock on a common resource. See this stackexchange q&a for example. Consider t concurrent queueable async transactions, all locking on the same resource. Randomly backoff by n secs ( n < 17) each transaction by sleeping, then requeueing the queueable.
By way of example, transaction 1 might back off by 3 secs, transaction 2 by 12 secs, transaction 3 by 1 sec, etc and when their backoff queueable job starts anew, they may be less likely to contend on a shared resource. Hence you have a range greater than 10 (secs) to introduce jitter delays.
You of course might need a sleep delay < 17 secs if the async transaction has already consumed a bunch of CPU before hitting some shared resource lock contention exception.