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

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" wrote in message
...
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

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

"Bob Phillips" wrote in message
...
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" wrote in message
...
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

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 wrote:

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

"Bob Phillips" wrote in message
...
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" wrote in message
...
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





--

Dave Peterson

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

RBS


"Dave Peterson" wrote in message
...
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 wrote:

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

"Bob Phillips" wrote in message
...
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" wrote in message
...
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





--

Dave Peterson

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


"RB Smissaert" wrote in message
...
Hang on, are you saying now that it is faster without
the variable after the Next?

RBS


"Dave Peterson" wrote in message
...
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 wrote:

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

"Bob Phillips" wrote in message
...
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" wrote in message
...
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





--

Dave Peterson

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



RB Smissaert wrote:

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

RBS

"Dave Peterson" wrote in message
...
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 wrote:

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

"Bob Phillips" wrote in message
...
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" wrote in message
...
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





--

Dave Peterson

--

Dave Peterson

On Sun, 27 Aug 2006, RB Smissaert wrote:

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).

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


"Don Wiss" wrote in message
...
On Sun, 27 Aug 2006, RB Smissaert wrote:

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).

I think perhaps you are all testing with nicely structured code. If you
sprinkled a few ifs and gotos around, wandering all over the place, like us
old fashioned real programmers used to do, the the compiler may not be able
to link a particular NEXT with its matching FOR without the variable
specified, and have to generate more complex code.

just a theory


"RB Smissaert" wrote in message
...
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

If it can't, then it won't be able to run the code.

If's and goto's still have rules that the compiler has to interpret.

Just another thought.

--
Regards,
Tom Ogilvy

"David Cox" wrote in message
...
I think perhaps you are all testing with nicely structured code. If you
sprinkled a few ifs and gotos around, wandering all over the place, like us
old fashioned real programmers used to do, the the compiler may not be able
to link a particular NEXT with its matching FOR without the variable
specified, and have to generate more complex code.

just a theory


"RB Smissaert" wrote in message
...
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

I had thought about that, but I have tested with a very complex For Next
loop and I still couldn't see the difference.
As Tom says it would be bad news if the compiler would be thrown by that.
Clever bits of software these compilers, especially at the speed they do it.

RBS

"David Cox" wrote in message
...
I think perhaps you are all testing with nicely structured code. If you
sprinkled a few ifs and gotos around, wandering all over the place, like us
old fashioned real programmers used to do, the the compiler may not be able
to link a particular NEXT with its matching FOR without the variable
specified, and have to generate more complex code.

just a theory


"RB Smissaert" wrote in message
...
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