Tecnicamente non dovrebbe avere alcun effetto. Ma devi ricordare che il valore passato è usato come minimo , e non un assoluto, quindi il sistema è libero di utilizzare invece l'intervallo più piccolo possibile.
Volevo solo sottolineare il comando time usato qui. Dovresti usare /usr/bin/time invece di solo time comando se vuoi controllare la memoria del tuo programma, cpu, time stat. Quando chiami time senza percorso completo, viene chiamato il comando time integrato. Guarda la differenza.
senza percorso completo:
# time -v ./a.out
-bash: -v: command not found
real 0m0.001s
user 0m0.000s
sys 0m0.001s
con percorso completo:
# /usr/bin/time -v ./a.out
Command being timed: "./a.out"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:10.87
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 0
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 220
Voluntary context switches: 10001
Involuntary context switches: 1
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
usa man time per /usr/bin/time manuale e usa help time per informazioni sull'ora integrate.
Dovrei guardare la fonte per esserne sicuro, ma la mia ipotesi è che non sia proprio "nessun effetto", ma probabilmente è comunque inferiore a usleep(1) - c'è ancora l'overhead della chiamata di funzione, che può essere misurabile in un ciclo stretto, anche se la chiamata alla libreria controlla semplicemente i suoi argomenti e ritorna immediatamente, evitando il processo più consueto di impostare un timer/callback e chiamare lo scheduler.