Jamie.

–

In addition, floating point arithmetic is noteably faster than read or write to Excel — which, of course, is not the same as load/store. I believe there is a small (but statistically significant) performance gain writing doubles instead of singles. Since writes are so time-consuming, this 2.8% improvement is equivalent to a 15% gain while reading and about a 70% math improvement. At least until someone proves otherwise, doesn’t this make using doubles almost a no-brainer?

Regards,
Keith

That said, the extra precision doubles provide means most algorithms don’t need to be optimized for prevention of rounding error. Start using nothing but singles, and most VBA programmers would likely introduce difficult to diagnose numeric bugs. Wouldn’t seem to make sense to chase slight performance improvement.

I believe Charles Williams add-in “High Resolution Timers” may be suitable to achieve a better accuracy: http://www.decisionmodels.com/downloads.htm

Kind regards,
Dennis

Private Declare Function GetTicks Lib “kernel32? Alias “QueryPerformanceCounter” (Tick As Currency) As Long

Private Function PerfTimer() As Double
Dim Tick As Currency
Call GetTicks(Tick)
PerfTimer = Tick / 357.9545@
End Function

Public Sub Test()
Dim nIter As Long, n1 As Long, n2 As Long
Dim x1 As Double, x2 As Double, x As Double

For n1 = 0 To 10
nIter = 10 ^ n1
x = PerfTimer()
For n2 = 1 To nIter
Call Option1
Call Option2
Next
x = PerfTimer() – x
Debug.Print “nIter = ” & Format(nIter, “#,##0?) & ” – Time = ” & Format(x, “0.000?)
If (x > 1) Then Exit For
Next

‘Option1 block
x1 = PerfTimer()
For n1 = 1 To nIter
Call Option1
Next
x1 = PerfTimer() – x1
Debug.Print “Option1 = ” & Format(x1, “0.00?) & “, scaled = 100.00?

‘Option2 block
x2 = PerfTimer()
For n1 = 1 To nIter
Call Option2
Next
x2 = PerfTimer() – x2
Debug.Print “Option2 = ” & Format(x2, “0.00?) & “, scaled = ” & Format(x2 / x1 * 100, “0.00?)
End Sub

In the floating-point case, however, timing differences are small. (I’m even partially convinced that ordering seems to matter, whether Option1 is called before Option2 or vice versa.) So I’ve repeated some of this analysis, a bit more carefully. Here’s Option1() for TestA — a “bare loop”:

Private Sub Option1()
Dim snTest As Double, rCell As Range
‘ snTest = 5
For Each rCell In ActiveSheet.Range(“Test”).Cells
‘ snTest = rCell.Value
‘ snTest = snTest * snTest / snTest * snTest / snTest * snTest / snTest * snTest / snTest
‘ rCell.Value = snTest
Next rCell
End Sub

Option2 is identical, except that snTest is a Single and in Option3 snTest is a Currency. TestB covers “arithmetic” and activates the lines snTest = 5 and snTest = snTest * snTest /… TestC covers “reads” with only the line snTest = rCell.value active. And TestD, with snTest = 5 and rCell.Value = snTest active.

The main sub Test was rewritten to turn off screen updating, reset calculation to manual (although that shouldn’t matter?), and to call the three subroutines in random order. Based on 100 replications, each using 100 iterations, the results are

Bare loop –

Doubles0.0342 (.0009) seconds per 100 iterations
Singles0.0333 (.0008) // seems faster by 2.4%, but that’s less than one standard-deviation//
Currency0.0341 (.0010)

Arithmetic

Doubles0.0346 (.0009) seconds per 100 iterations
Singles0.0342 (.0008)
Currency0.0456 (.0011) // 32% slower; easily significant //

Reads

Doubles0.1392 (.0014) seconds per 100 iterations
Singles0.1383 (.0015)
Currency0.1395 (.0014)

Writes

Doubles0.8277 (.0028) seconds per 100 iterations
Singles0.8508 (.0027) // 2.8% slower, significant //
Currency1.0263 (.0070) // 24% slower, easily significant //

Given this, I can’t see any good reason to deviate from the practice of always using doubles. The results do suggest, however, that writes are way more important than reads in determining code speed — even when calculation and screen updating are turned off. This makes sense, but the magnitude of the difference surprised me.

This, by the way, is on a 2.53GHz Pentium 4, XP, and Excel 2002. My experience, of late, is that relative speeds are not so much hardware dependent — although absolute speeds certainly vary.

Keith

What is your hardware plateform ? Whatever the method you use you should give the hardware platform and mainly the cpu. As you may know AMD vs Intel core cpu may have important differences in calculating (interpreting) long/double.

Secondly, as Ross said, I would use the API function GetTickCount (which is known as better for time performance) – I don’t know about the API function QueryPerformanceCounter suggested by Keith Johnson.

When used to time code which executes quickly it is best to repeat the test procedure (e.g. 100 times, 1000 times etc.) until 0.055 seconds is insignificant in the result.