Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / Using the "wait" command

Author
Message
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 20th Oct 2013 10:19
There's been a lot of debate about whether or not a coder should use GOTO. Personally, I don't think it's a good idea because it can make code management a pain in the butt, especially when tracking bugs.

But I've noticed a lot of beginner coders like to use wait in their programs and it got me thinking, I don't believe I've ever had to use it before. I'd have to say it's bad practice for setting up time delays in that manner. What do you all think?

Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 20th Oct 2013 12:54


Wait is only used because beginner coders don't know about proper state management, and it's easy to use for very simple applications.

Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 20th Oct 2013 13:27 Edited at: 20th Oct 2013 13:29
LOL Very true.

In the .NET world; sleep (wait) is used to pause a thread while an object is being synchronized, or to poll a process. In DBPRO it is being used a lot as a delay mechanism, mostly in small programs.

The Matrix1 Nice Wait / Nice Sleep or the API call alternatives are much more CPU resourcefull; these are the only good way to make DBPRO not do anything while it is idle or not required.

I wouldn't personally put it in the same league as GOTO.

Seditious
10
Years of Service
User Offline
Joined: 2nd Aug 2013
Location: France
Posted: 20th Oct 2013 14:24
Quote: "Personally, I don't think it's a good idea because it can make code management a pain in the butt, especially when tracking bugs."


Only if you use it to jump through major parts of the code. Goto is does have its uses.

Your erased has been moderated by signature.
Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 21st Oct 2013 00:39
I think if you have a lot of nested loops that you want to leave, goto is a good option. Having to trick the loops into stopping at the right time (especially in nested loops where you have to track states) will inevitably complicate your code more and make it harder to understand, which is the reason people complain about 'goto' in the first place. Usually it's bad, but "only a sith thinks in absolutes".

As for 'wait', I've also not found myself using it since the very early days of DBP. I believe good state management is a better solution, but if you're making a small simple application, why complicate it with complex states when a simple 'wait' is much simpler and more easily understood? Don't be a sith!

"everyone forgets a semi-colon sometimes." - Phaelax
easter bunny
11
Years of Service
User Offline
Joined: 20th Nov 2012
Playing: Dota 2
Posted: 21st Oct 2013 01:02 Edited at: 21st Oct 2013 01:05
Quote: "only a sith thinks in absolutes"

Yep



But I do use goto occasionally, normally to skip code, although an if/elseif/endif works better most of the time. When you've got for/next loops, you sometimes need a goto.


formerly MissJoJo - Audacia Games
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 21st Oct 2013 01:34 Edited at: 21st Oct 2013 01:37
Lol, the DBPro implementation of sleep / wait is pretty much like so:


Wonder what they were thinking there...
Thus yeah, I'd say they're useless. The proper thread suspending versions are quite useful for reducing CPU usage though.
Or I guess you can use them for very simple timing purposes, like some people have already said.


Quote: "I think if you have a lot of nested loops that you want to leave, goto is a good option. Having to trick the loops into stopping at the right time (especially in nested loops where you have to track states) will inevitably complicate your code more and make it harder to understand"

Nothing against goto's here, but isn't it better to just put such functionality in a function and return from it when you need to exit the nested loops?


"Why do programmers get Halloween and Christmas mixed up?"
Mobiius
Valued Member
21
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 21st Oct 2013 02:39
Quote: "I think if you have a lot of nested loops that you want to leave, goto is a good option"

No. Simply no. If you have a lot of nested loops, then your code is too messy, and you need to learn how to modularise, or how to use proper state management.

Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 21st Oct 2013 03:17 Edited at: 21st Oct 2013 03:18
Hehe, I think this wait command topic is going to turn into another GOTO command debate.

I haven't used GOTO for years; the last time I used it was for a tutorial on why not to use GOTO. As stated it can be used like an iteration skipper:



Some people may prefer that to:



Anyway, on with the topic about Wait... (year right!)

Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 21st Oct 2013 07:07
Quote: "I think if you have a lot of nested loops that you want to leave, goto is a good option. "

That's why we have the exit command, which I see Chris also just pointed out.

Quote: "why complicate it with complex states when a simple 'wait' is much simpler and more easily understood?"

I'm thinking more along the lines of production code, not small little testing examples. For small things, I'm sure we all do things we shouldn't.

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Oct 2013 13:22
If you goto from a For...Next loop, you invariably leave garbage behind, because the loop is never completing, it's probably storing a pointer back to that loop every time you goto from it. At least with exit, the loop knows to terminate.

One thing with Wait though... it actually makes perfect sense to use it with frame rate locked programs. Like, it's easier to say run this game at 50fps, and program for that. Then, any leftover performance can be handed back using the Wait command. You could use timer based movement, use the whole processor to run your game at 2000fps - or you can lock the frame rate and use Wait and only use about 10% of the processor. With laptops and mobile devices working with batteries, it makes a lot of sense. A consistant frame rate is far easier to code with, than timer based movement - timer based coding can very quickly turn into a soup sandwich.

I am the one who knocks...
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 21st Oct 2013 13:41 Edited at: 21st Oct 2013 13:43
Quote: "At least with exit, the loop knows to terminate."


Thanks for that information; I thought that the garbage was retained until exiting the function/label stack anyway since you can access the variables declared inside of the loop from the outside? Am I wrong? (Although I still do not use that procedure)


I am doing what you suggested with battery consumption and CPU effeciency; but with the Matrix1 version of the command; where the DBPRO version uses roughly 70% of a CPU on my machine, the Nice Wait/Sleep command uses up 20%.

Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 21st Oct 2013 13:46
Quote: "Then, any leftover performance can be handed back using the Wait command."

Only it isn't, the built-in wait function performs a busy wait.


"Why do programmers get Halloween and Christmas mixed up?"
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Oct 2013 13:51
Ahh, maybe I'm thinking of the sleep command - either way I think it's about the use of such a command. I tend to use an internal DLL call instead of wait - just pointing out that the technique can be used for the power of good

I am the one who knocks...
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 21st Oct 2013 16:25
I can't remember when I last used a goto and don't think I've ever used it in DBpro when I've coded from scratch (no doubt someone will now dig up a demo of mine where I've used it out of sheer laziness ).

However, I've used wait key a lot in simple demos since the code is easily understood. In contrast a few gotos rapidly make code unreadable and error prone. An exception might be when it's used to skip a single line or block of code such as



but even there a simpler solution might be



The arguments against wait seem rather subtle by comparison. What exactly is gained by avoiding wait?

My impression is that the goto issue is about programming style, readability and error proneness, whereas the wait issue is about program efficiency. Is that the general view?



Powered by Free Banners
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Oct 2013 16:50 Edited at: 21st Oct 2013 16:54
I think so. Using Wait is wasteful when it's just there to cause a useless delay. To me, it's almost like program maturity.

It might be considered immature to use Wait, like your program saying ''Hey computer, do nothing until I'm ready, no matter what else might be going on''

But, if used differently, it can pass the leftover performance back to other processes, albeit using different commands - but I'm assuming the discussion is about the use of programmed delays. Like, a program might say, I have 58ms leftover that I don't need, sleep the program for 57ms, giving that back to other processes rather than just waiting for 57ms. It's more efficient to work that way, to have the program use the minimum resources that it needs and pass back the leftovers. DBPro and AppGameKit don't exactly like to play along with other programs, they are kinda selfish in the way they work, and they let us be selfish as well, unless we take steps.

So besides all this waffle, I'd say that using a wait command to just 'wait' is inefficient, but using a wait command to properly 'sleep', is very efficient - I find that it can actually be fun to chase processor and memory usage down, sometimes anyway, the main thing is allowing your program to run on less-powerful devices.
I've said it before, but compatibility problems will attract bad app reviews like flies to... poop.

I am the one who knocks...
Libervurto
17
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 21st Oct 2013 17:30
Quote: "I believe good state management is a better solution, but if you're making a small simple application, why complicate it with complex states when a simple 'wait' is much simpler and more easily understood?"

When is WAIT ever a suitable alternative though?

Quote: "I'd say that using a wait command to just 'wait' is inefficient, but using a wait command to properly 'sleep', is very efficient - I find that it can actually be fun to chase processor and memory usage down, sometimes anyway, the main thing is allowing your program to run on less-powerful devices."

I am not familiar with using SLEEP in this way (there is a separate SLEEP command in DBP right?), is this just used for when you have a static screen displayed? How do you know when to resume the program?


Formerly OBese87.
Seditious
10
Years of Service
User Offline
Joined: 2nd Aug 2013
Location: France
Posted: 21st Oct 2013 17:38 Edited at: 23rd Oct 2013 14:54
Both the native (DBPro) wait and sleep commands use busy waiting, which sucks up a lot of CPU power and as a result drains battery pretty quickly on mobile devices. Other than that, a properly implemented 'wait' command can be handy in procedural (as opposed to real-time) applications, where you don't need anything to happen during that time period.

Quote: "If you goto from a For...Next loop, you invariably leave garbage behind, because the loop is never completing, it's probably storing a pointer back to that loop every time you goto from it"


Pretty sure this doesn't happen in DBPro; it's not necessary to store a pointer to the start of the loop since it has a fixed address. It should be safe to jump out of any standard loop. Conversely, jumping into a any loop is a very bad idea since it needs to initialize the loop variables first.

Admittedly goto doesn't have very many uses (and is potentially dangerous to use in DBPro since labels aren't scope-unique), but I've found a few uses where it is better than some alternatives. If I remember correctly, these two cases (C++):

1. In self-contained functions that require their own cleanup routine:



In a proper implementation of this function operations would occur between the checks, requiring cleanup at the end of the function. You could alternately stack the IF statements inside each other, but this would look messy and would require that you write separate cleanup code after each step.

2. Multiple nested loops where an abstract problem occurs:



You could use break (exit) and store an error flag in a variable which is then checked by each loop, but that would require more unnecessary code.

In both of these examples goto is beneficial and has no drawbacks.

Your erased has been moderated by signature.
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 21st Oct 2013 17:39
Well you specify the delay, like Sleep 1000 would sleep for 1 second. I would tend to work out the frame rate I want, and how many milliseconds that takes, like a game running at 50fps will need to update every 20ms. If each sync, the time is only 8ms, then I have 12ms left - and if I sleep for 12ms then that's passing performance back to other processes. Even with crusty old DBPro it's possible to greatly reduce processor usage this way. It's difficult to claw anything back with timer based movement.

My current project only needs to run at 30fps, anything more than that is a waste, and it's targeted at tablets and mobile platforms - so it's my best option to just sleep each loops leftover milliseconds. It's a puzzle game too, so I think it's better to have a consistent update rather than inconsistent timer based updates.

I am the one who knocks...
Jeff Miller
19
Years of Service
User Offline
Joined: 22nd Mar 2005
Location: New Jersey, USA
Posted: 23rd Oct 2013 01:10
I take it that the collection of "nice" wait commands in IanM's MatrixUtil_15 plugin are not of the "busy wait" type that Seditious mentions. IanM describes them as "system friendly". They have been very useful to me for years. Does anyone happen to know generally how the lower processor load is achieved by these commands?
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 23rd Oct 2013 01:21
They simply suspend your thread for (approximately, note that it isn't guaranteed to keep the specified time; it will sleep at least for as long as you tell it but it might be slightly longer too if I recall correctly) the amount of milliseconds you send as a parameter to the Sleep() function. This means that the processor will not process your thread further for that time and as such it can deal with other threads (/processes / applications).


"Why do programmers get Halloween and Christmas mixed up?"
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 23rd Oct 2013 14:31
In a multi-threaded environment, sure there is a need for sleep/wait in that regards. But that's a little different than DB's linear structure.

Login to post a reply

Server time is: 2024-05-29 05:26:34
Your offset time is: 2024-05-29 05:26:34