[RESOLVED] Optimization needed? Application taking a pause

Hi.

I have a procedure that have been working good for years now. Why change it you might say? Well I wanted to make sure it's optimized (I doubt it is). I know there are real optimization gurus here so I'm giving it a try.

Sometimes I want my application to take a 'pause', to wait for some stuff to process, or a webpage to load (YES, even tho the browser has functions for this). Here is my code:

Usage:

Code:

---

Call proWait(10) '10 seconds

---

Procedure:

Code:

---

Public Sub proWait(WaitTimeInThousands As Long)
    '################################################
    'USING THE 'tmrWait' timer
    '################################################
    iWaitLoopCount = 0
   
    frmForm.tmrWait.Interval = WaitTimeInThousands
    frmForm.WaitTimerEnded = False
    frmForm.tmrWait.Enabled = True
   
    Do While frmForm.WaitTimerEnded = False
        iWaitLoopCount = iWaitLoopCount + 1
        If iWaitLoopCount = 40000 Then
            iWaitLoopCount = 0
            DoEvents
        End If
    Loop
    'DoEvents
End Sub

---

Code:

---

Private Sub tmrWait_Timer()
    WaitTimerEnded = True
End Sub

---

I had some 'remmed' lines in this code that I did not paste here, which were using the 'sleep' function. I don't know why I didn't use that - I guess I might have had problem in the past using it. It might be a good idea to try to use it? I guess that using 'sleep' was preventing my app, or browser, or whatever on it, to keep on running properly, hence rendering useless the use of sleep since nothing would process meanwhile.

In clear, I need a nice little function that would take a pause.

You might notice the 'iWaitLoopCount' loop in my code. I agree - this is weird. I think that without that loop, my whole procedure was too much of a resource hogger. And it seemed to work good with that loop inside the loop. I think this was used to avoid calling 'DoEvents' too often.

One suggestion might be to simply wait for 'Private Sub tmrWait_Timer' to trigger and act at that point, eliminating the need of a loop, but I need my code to keep executing from where the 'proWait' procedure was called...

Any comments grealy appreciated.

Thanks.

What are you trying to accomplish?

Optimizing usually means tossing out the old and starting fresh.

For you, it seems, you may want to split up the 'code that's executing' where you call proWait, just as Split() does for strings, split your procedures into multiple procedures, and indeed, simply wait(for instance with a timer) between calls to the different procedures.

Hi FireXtol, thanks for your reply.

I thought about splitting my code in procedures and act when a timer is triggered but this would involve too much work.

I use my proWait function at a lot of different places in my code. I add some here and there and remove some others from time to time.

While I agree with you that optimizing often needs you to rewrite the code from scratch, this wouldn't be a factor here since I'm only concerned about this 6-7 lines function. I really don't think I could redesign the core of my 'very dynamic' app and modulate it further more.

I guess I'll stick with my current code since, as I specified in my first post, it does work quite good.

I just thought someone could come up with a better idea than my "If iWaitLoopCount = 40000 Then" line of code (to prevent DoEvents from being executed too often)

I've done some other tests with 'sleep' and that really is not a good option as it freezes the whole screen (obviously) while it's sleeping. I believe this is useful when the app has nothing processing at that time.

Thank you!

The downside here is you're using the evil DoEvents() call. This can result in all sorts of inadvertant re-entrancy that can cause data loss or stack overflows, especially if you have events raised in reaction to external (non-UI) events.

There are times and places for both DoEvents() and Sleep() calls, but they shouldn't be used indiscriminately as you do here. You are always better off writing event-driven code instead of doing something like this. However it isn't always possible either. I really think using something like your "proWait" will tend to cause erratic program behavior and hard to diagnose bugs, and it encourages you to write "straight line" processing code within event handlers.

If you have a large chunk of crunching to do it is generally better and safer to either (a.) diviide it into smaller chunks driven by a Timer event, or else (b.) use a "shell and raise completion event" technique to run the crunching in a formless child process, preferably using a formless program linked for the Console subsystem. Both of these can be hard to retrofit into an existing application however.

There really isn't anything to optimize here either: if you think about it, you're either spending processor time calculating + 1 or having a call into DoEvents. Both ways your application is hitting 100% in processor usage as it is constantly using it. Adding Sleep would drop the processor usage, because Sleep tells Windows to not process the application code for given amount of ms, but then again you may hit the DoEvents problem which will start causing unexpected problems (as explained by dilettante above).

All code you have relying on proWait could probably more or less easily rewritten to a purely timer evented code. Event based coding isn't all that hard. If you give us a complete enough example of a place you've used proWait we can probably provide suggestions on how to rewrite it.