Is a particular loop faster then another?
What I mean is, is there a loop that executes faster then the others?

Not really. Just use the one that best matches what you want.

If you try and do what one loop does using another, you'll only at best match it's speed.

I'm too lazy to test this, but a loop like:

while escapekey()=0
[instructions]
endwhile

VS:

do
[instructions]
loop

(provided the escapekey is disabled)

The former is checking a condition while the latter is not, so there must be a difference, however slight - though in practice you'd want a way to exit the loop, which requires a condition check so in the end, probably not no

My advice...

don't worry about the loop command, think about the loop content.
Bearing in mind that the purpose of a loop is to do something many times, it's important to make the code inside the loop as efficient as possible.

If a loop executes 10,000 times, each operation is an extra 10,000 lines. remember, a complex mathematical equation is a collection of smaller ops.

Having said all that, I think you'll struggle to drag your code down by any degree. My current code has a loop that is executed 36,000 times. There are exactly 50 lines of code in the loop, and it completes in 50 milliseconds (whilst downloading from the internet at 50K / sec at the same time). That's the equivalent of 200 FPS, which means I can do 4 times as much and still be faster than the graphical output, synched at 50 FPS.

My machine is no monster either, 1Ghz P3.

Danmatsuma: That was my point. To make the two loops equivalent, you would have to test the ESCAPEKEY() within your DO...LOOP anyway.

Actually, I've thought of something for FOR...NEXT loops.

The first loop would be faster than the second:



This is because the second piece of code has to keep fetching the value of LastSprite from memory. The small difference it would make though is probably not worth the effort ... so I really don't know why I mention it

This is because the second piece of code has to keep fetching the value of LastSprite from memory...

Unless you know how the underlying code works, this isn't necessarily true.

For example, some languages always read arrays from back to front, no matter which element it's aiming for. In this case it would be faster to put 10 elements in the last 10 positions of a 10,000 long array than it would be to put 10 elements in the first 10 positions of a 20 long array.

Some things just don't make any sense, unless you're a micro-coder.

Nope the two for next loop aren't faster than eachother. The first is as fast as the second. Even with a milion value the loops are equal. Try this code and see for yourself. The results are the same.

StevieVee: I actually know this for a fact. I have studied various parts of the assembly code that the compiler produces. The final comparison value is always retrieved from memory if it is a variable value.

It's the difference between this for a hard-coded value
mov eax,0f4240h

and this for a variable

mov eax,dword ptr dsvar addr]


RTSpider: There are several things wrong here.
1) Due to processor caching, the effects are not large.
2) Use SYNC ON at the top of your program to stop your code running off and hiding the differences by fitting into the vertical sync.

Most of the time I get almost no difference on my 850mhz PIII, but with very large numbers, and code inside the loop that blows the cache, the difference is just about detectable.

As I said, the difference is not really worth mentioning.

Wow, a real programmer! It's years since I checked out the assembler mnemonics for a program. In fact, I think it was on a Dragon 32, some people in here won't know what a Dragon 32 is!

The Dragon 32 ran.... Microsoft Basic version 1.0. Not a lot of people know that.

If you don't have 'SYNC ON', then a FOR-NEXT loop is by FAR the fastest (as it doesn't force a SYNC, or check for ESC key (to my knowledge)). With 'SYNC ON' then FOR-NEXT and DO-LOOP seem fairly evenly matched, while the WHILE loop lags slightly behind. (just been discussing this over at DBDN).

Mmmm, green!

Oh, and that smiley in my previous post was supposed to be : and [

Conrad, who writes code without using SYNC ON anyway

IanM: hehehe it's always worth mentioning, knowing those 'lil differences is what used to make programming an art Glad to see someone's still checkin' under the hood

Conrad, who writes code without using SYNC ON anyway

Are you reffering to me? I just wrote this in a short time, so please...

In my experience, FOR ... NEXT loops are slightly faster than DO .. LOOPs

This is due to the illogical integration of message processing in the DO .. LOOPs.

^^ This only happens in DBP AFAIK.

RTSpider: Not you mate. I accept that short example code just shows the point you are getting at, and not necessarily how you actually code.

Rob K: I can just see it now, people producing the following code to get a few extra cycles



... trust me, it does actually work as an infinite loop. And don't try it without a sync inside the loop, otherwise escape won't end the program.

Personally, I'd prefer if DBPro only checked windows messages every sync, or had a separate function to do so.

I know that... I normally write my own EscapeKey() handler anyway.

The disadvantage with For ... Next as a main proggie loop is that it can introduce confusion.