Most people use the following paradigm:
Option Explicit
Public Declare Function QueryPerformanceFrequency Lib "kernel32" _
(ByRef freq As Currency) As Long
Public Declare Function QueryPerformanceCounter Lib "kernel32" _
(ByRef cnt As Currency) As Long
Private freq As Currency, df As Double
Sub testit()
Dim st As Currency, et As Currency, dt As Double
QueryPerformanceCounter st
'.... whatever you want to measure ....
QueryPerformanceCounter et
dt = convertmytimer(et - st)
MsgBox Format(dt, "0.000000000") & " sec"
End Sub
Function convertmytimer(ByVal dt As Currency) As Double
If freq = 0 Then QueryPerformanceFrequency freq: df = freq
convertmytimer = dt / df
End Function
But they are fairly naive about it.
For example, if you simply measure Range("A1").Dirty (in Automatic calculation mode) or Range("A1").Calculate (in Manual calculation mode), much, if not most, of what you measure is overhead that is unrelated to measuring the formula in A1.
The source of the overhead is two-fold: (a) VBA overhead due to first-time execution of statements ("delayed binding"); and (b) system overhead in interprocess communication between the VBA and Excel threads.
So it is not uncommon for people to conclude that there is no significant performance difference, simply because the formula execution time is so very small compared to the overhead.
Secondly, if you measure the formula execution many times, you will probably notice a significant variability in the execution time. There are many possible reasons for the variability. But the point is: if you measure only one time, you might not measure the minimum or even the typical time.
There is more to be said. But suffice it to say: performance measuring is as much art as it is science. GIGO.