For Next loop faster with counter after Next?

[RB Smissaert]

Read in the book Visual Basic for Applications in 21 days by Matthew Harris
(third edition) that putting the loop counter after the Next would make the
loop faster:

For i = 0 to 10
'code
Next i

I can see it makes the code clearer, but I didn't think it made it any
faster and on simple testing I can see no difference:

Option Explicit
Private lStartTime As Long
Private Declare Function timeGetTime Lib "winmm.dll" () As Long

Sub StartSW()
lStartTime = timeGetTime()
End Sub

Sub StopSW(Optional ByRef strMessage As Variant = "")
MsgBox "Done in " & timeGetTime() - lStartTime & " msecs", , strMessage
End Sub

Sub test()

Dim i As Long
Dim c As Long
Dim n As Long

StartSW

For i = 0 To 10000
For c = 0 To 1000
n = i + c
Next
Next

StopSW

End Sub


Is there any truth in this?


RBS

 

[Bob Phillips]

I would have expected it to be true, but not significantly so.

I did a 100 times repetitive loop of your code and found it to be approx 1%
faster, which I think sounds about right.

But it is much nicer code IMO irrespective.

--
HTH

Bob Phillips

(replace somewhere in email address with gmail if mailing direct)

 

[RB Smissaert]

OK, thanks, 1% faster will be worth it for me and as you say it looks
better.
Couldn't see the speed difference, but I believe you.

RBS

 

[Dave Peterson]

I like to see the variable in the Next statement.

But I have seen Dana DeLouis do this:

For i = 0 to 10
'code
Next 'i

It's kind of the best of both worlds???

 

[RB Smissaert]

Hang on, are you saying now that it is faster without
the variable after the Next?

RBS

 

[Tom Ogilvy]

I put your code within a loop of 50 and ran each case 4 times. I saw no
difference. It varied by run which was faster, but the difference was never
more than 2/10ths of a percent.

--
Regards,
Tom Ogilvy

Hang on, are you saying now that it is faster without
the variable after the Next?

RBS

 

[Dave Peterson]

From what I've read (I've never tested), Next without the variable is faster.

 

[Tom Ogilvy]

That was the average of 50 values/runs with compared to the average of 50
values/runs without.

4 such comparisons.

--
Regards,
Tom Ogilvy

I put your code within a loop of 50 and ran each case 4 times. I saw no
difference. It varied by run which was faster, but the difference was
never more than 2/10ths of a percent.

 

[RB Smissaert]

I couldn't see a difference either, but the book I mentioned states:

Although placing the counter variable after the Next statement is optional,
it greatly improves
the readability of your program code. Also, VBA does not have to spend time
determining which
counter variable belongs with that Next statement, and your loops execute
faster.
(page 376)

It seems though that VBA knows already at compile time what counter variable
belongs to what
For because when I do this:

For i = 0 to 10
For c = 0 to 5
'code
Next i
Next c

It won't compile: Invalid Next control variable reference.

I just take it that it won't make a difference, but it looks better.

RBS

I put your code within a loop of 50 and ran each case 4 times. I saw no
difference. It varied by run which was faster, but the difference was
never more than 2/10ths of a percent.

 

[RB Smissaert]

I have read that it is equal and that it is faster with the counter
variable, but never
that is slower with the counter variable.
I just take it it is the same or the difference is unmeasurable small.

RBS

 

[Jim Cone]

With the comment ('c and 'i) took 0.57 seconds.
Without the comment (c and i) took 0.84 seconds.
Averages of five tries for each.
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware

Sub test()
Dim lStartTime As Long

Dim i As Long
Dim c As Long
Dim n As Long
lStartTime = timeGetTime

For i = 0 To 10000
For c = 0 To 1000
n = i + c
Next 'c
Next 'i

MsgBox "Done in " & Format$((timeGetTime - lStartTime) / 1000, "###.000") & " Seconds"
End Sub
'-----------------

I have read that it is equal and that it is faster with the counter
variable, but never
that is slower with the counter variable.
I just take it it is the same or the difference is unmeasurable small.

RBS

 

[RB Smissaert]

I get similar figures with your exact code, which is a nuisance as I have
spent more
than an hour adding all the counter variables to a large .xla file!
Not sure now why I didn't see this difference with the previous code.

RBS

With the comment ('c and 'i) took 0.57 seconds.
Without the comment (c and i) took 0.84 seconds.
Averages of five tries for each.
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware

Sub test()
Dim lStartTime As Long

Dim i As Long
Dim c As Long
Dim n As Long
lStartTime = timeGetTime

For i = 0 To 10000
For c = 0 To 1000
n = i + c
Next 'c
Next 'i

MsgBox "Done in " & Format$((timeGetTime - lStartTime) / 1000,
"###.000") & " Seconds"
End Sub
'-----------------

I have read that it is equal and that it is faster with the counter
variable, but never
that is slower with the counter variable.
I just take it it is the same or the difference is unmeasurable small.

RBS

 

[Tom Ogilvy]

Times shown are the average of the 50 loops. Times in milliseconds

Run1
352.78 Without
351.88 With
0.002551165 proportional difference

Run 2
352.18 Without
352.5 With
0.000907801 Proportional difference

Run 3
352.2 Without
351.88 With
0.000908575 Proportional difference

Run 4
352.5 Without
353.44 With
0.00265957 Proportional difference


----------------------------------------------
Option Explicit
Private lStartTime As Long
Private Declare Function timeGetTime Lib "winmm.dll" () As Long

Sub StartSW()
lStartTime = timeGetTime()
End Sub

Sub StopSW(Optional ByRef strMessage As Variant = "")
Debug.Print timeGetTime() - lStartTime
End Sub

Sub test()

Dim i As Long
Dim c As Long
Dim n As Long
Dim k As Long
For k = 1 To 50
StartSW

For i = 0 To 10000
For c = 0 To 1000
n = i + c
Next
Next
StopSW
Next k

Debug.Print ' put in a blank line to separate results

For k = 1 To 50
StartSW

For i = 0 To 10000
For c = 0 To 1000
n = i + c
Next c
Next i
StopSW
Next k
End Sub

--
Regards,
Tom Ogilvy

With the comment ('c and 'i) took 0.57 seconds.
Without the comment (c and i) took 0.84 seconds.
Averages of five tries for each.
--
Jim Cone
San Francisco, USA
http://www.realezsites.com/bus/primitivesoftware

Sub test()
Dim lStartTime As Long

Dim i As Long
Dim c As Long
Dim n As Long
lStartTime = timeGetTime

For i = 0 To 10000
For c = 0 To 1000
n = i + c
Next 'c
Next 'i

MsgBox "Done in " & Format$((timeGetTime - lStartTime) / 1000,
"###.000") & " Seconds"
End Sub
'-----------------

I have read that it is equal and that it is faster with the counter
variable, but never
that is slower with the counter variable.
I just take it it is the same or the difference is unmeasurable small.

RBS

 

[RB Smissaert]

I think I didn't see the difference as it needs a forced recompile. When I
do that it seems that indeed leaving
the counter variable out is faster.

RBS

I get similar figures with your exact code, which is a nuisance as I have
spent more
than an hour adding all the counter variables to a large .xla file!
Not sure now why I didn't see this difference with the previous code.

RBS

 

[Don Wiss]

Read in the book Visual Basic for Applications in 21 days by Matthew Harris
(third edition) that putting the loop counter after the Next would make the
loop faster:

For i = 0 to 10
'code
Next i

I can see it makes the code clearer, but I didn't think it made it any
faster and on simple testing I can see no difference:

I can't imagine why it would make a difference. The first time the code is
run it gets pseudo-compiled. Both would compile to the same thing. Any
difference you might get (like the 1%) would come from one case having to
compile first, and the other case not having to. So before any comparison
you should press Debug -> Compile to put both on equal footing.

Don <www.donwiss.com> (e-mail link at home page bottom).

 

[RB Smissaert]

I did compile Jim's code before running both options and still I had the
same difference as he had.
For some reason now however I can't reproduce that anymore.
I agree that logically one would expect it to be the same and I think now
that it is indeed the same.
So, luckily I didn't waste an hour's work then!

RBS

 

[Tom Ogilvy]

using Jim's code:

With: Done in .515 Seconds
With: Done in .500 Seconds
With: Done in .516 Seconds
With: Done in .515 Seconds
With: Done in .515 Seconds
With: Done in .516 Seconds
With: Done in .515 Seconds

Without: Done in .360 Seconds
Without: Done in .344 Seconds
Without: Done in .359 Seconds
Without: Done in .344 Seconds
Without: Done in .375 Seconds
Without: Done in .375 Seconds

With: Done in .359 Seconds
With: Done in .344 Seconds
With: Done in .375 Seconds
With: Done in .343 Seconds
With: Done in .344 Seconds
With: Done in .360 Seconds

Without: Done in .359 Seconds
Without: Done in .360 Seconds
Without: Done in .344 Seconds
Without: Done in .360 Seconds
Without: Done in .343 Seconds
Without: Done in .344 Seconds

With: Done in .344 Seconds
With: Done in .343 Seconds
With: Done in .360 Seconds
With: Done in .360 Seconds
With: Done in .360 Seconds
With: Done in .359 Seconds

Without: Done in .359 Seconds
Without: Done in .360 Seconds
Without: Done in .359 Seconds
Without: Done in .359 Seconds
Without: Done in .344 Seconds
Without: Done in .359 Seconds

Except for the first run "with" variables on the end of the Next statement,
there isn't a difference.

If I alternate on each run:
Without: Done in .359 Seconds
With: Done in .360 Seconds
Without: Done in .375 Seconds
With: Done in .360 Seconds
Without: Done in .344 Seconds
With: Done in .344 Seconds
Without: Done in .344 Seconds
With: Done in .344 Seconds
Without: Done in .359 Seconds
With: Done in .360 Seconds


Why the first time anomaly - could depend on what else the system is doing.
Code timing in a multitasking environment is difficult

--
Regards,
Tom Ogilvy

I get similar figures with your exact code, which is a nuisance as I have
spent more
than an hour adding all the counter variables to a large .xla file!
Not sure now why I didn't see this difference with the previous code.

RBS

 

[RB Smissaert]

Yes, thanks, I can see now that the timings are the same.
Maybe it was different in Excel 97 and that might explain the book
statement.

RBS

using Jim's code:

With: Done in .515 Seconds
With: Done in .500 Seconds
With: Done in .516 Seconds
With: Done in .515 Seconds
With: Done in .515 Seconds
With: Done in .516 Seconds
With: Done in .515 Seconds

Without: Done in .360 Seconds
Without: Done in .344 Seconds
Without: Done in .359 Seconds
Without: Done in .344 Seconds
Without: Done in .375 Seconds
Without: Done in .375 Seconds

With: Done in .359 Seconds
With: Done in .344 Seconds
With: Done in .375 Seconds
With: Done in .343 Seconds
With: Done in .344 Seconds
With: Done in .360 Seconds

Without: Done in .359 Seconds
Without: Done in .360 Seconds
Without: Done in .344 Seconds
Without: Done in .360 Seconds
Without: Done in .343 Seconds
Without: Done in .344 Seconds

With: Done in .344 Seconds
With: Done in .343 Seconds
With: Done in .360 Seconds
With: Done in .360 Seconds
With: Done in .360 Seconds
With: Done in .359 Seconds

Without: Done in .359 Seconds
Without: Done in .360 Seconds
Without: Done in .359 Seconds
Without: Done in .359 Seconds
Without: Done in .344 Seconds
Without: Done in .359 Seconds

Except for the first run "with" variables on the end of the Next
statement, there isn't a difference.

If I alternate on each run:
Without: Done in .359 Seconds
With: Done in .360 Seconds
Without: Done in .375 Seconds
With: Done in .360 Seconds
Without: Done in .344 Seconds
With: Done in .344 Seconds
Without: Done in .344 Seconds
With: Done in .344 Seconds
Without: Done in .359 Seconds
With: Done in .360 Seconds


Why the first time anomaly - could depend on what else the system is
doing. Code timing in a multitasking environment is difficult

 

[Tom Ogilvy]

Who is the author.

Like you, maybe they were easily persuaded by 5 samples when 200 samples
spoke otherwise.

 

[RB Smissaert]

Author is Matthew Harris.

RBS

Who is the author.

Like you, maybe they were easily persuaded by 5 samples when 200 samples
spoke otherwise.