I have a sample code here:
Dim a As Boolean = False
Private Sub Timer1_Tick(sender As Object, e As EventArgs) Handles Timer1.Tick
If a = True Then
Console.WriteLine("Example of a task that needs to be done during tick event")
End If
End Sub
You can see there that I have a timer tick event, but the event can only be activated if and only if certain conditions are met, which in my case it is a = true. With that code, I am confident enough that unless I let a = true, it will disregard the tick event.
Do you think that it is a good idea to depend on the conditions inside the tick event instead of stopping the timer with timer1.stop()?
3
Depends. How many timers, how often, what environment. If you run a timer pointlessly sixty times a second on an iPhone, you are wasting significant amounts of energy and reduce the battery life, because every time the timer runs the CPU has to go up from sleep to full speed and back again, which is very expensive, if you do it sixty times per second. If you have a server with 128 cores, and your timer runs once an hour, nobody cares.
Coming from an embedded development background, I think it’s generally a good idea to free unused resources. This still holds true for current environments and systems, how powerful they may be – a resource not allocated is one you can use elsewhere (in this case, as pointed out above, CPU cycles and battery power). And of course there are exceptions to the rule, e. g. to optimize for speed by preallocation, or prevent race conditions, which you should only do when you’re sure that you’ll need it to meet some requirement(s).
In this case this is not premature optimization, as you already know when the resource is unused; no detailed profiling or analysis necessary, no guessing of future requirements involved. In the time you spend thinking about whether or not you could already have done it.
I am confident enough that unless I let
a = true, it will disregard the tick event.
No, it won’t.
The line won’t be written to the console, but Timer1_Tick will be called and the condition will be evaluated.
In terms of performance, it won’t matter much in most cases: otherwise, you’ll see its effects when profiling your application.
On the other hand, even if it has no major impact on the performance, is it really necessary to keep a timer ticking? Why not turning it on and off when needed?
Doesn’t sound like you need a timer. Here is some code that shows an alternative. First the replacement code for the timer.
Public Sub TimerReplacement()
Do
doit.WaitOne()
If isrun.WaitOne(0) Then
'code here
Stop
Else
Exit Do
End If
Loop
Debug.WriteLine("END")
End Sub
Some control variables
Dim isrun As New Threading.ManualResetEvent(True) 'app is running
Dim doit As New Threading.AutoResetEvent(False) 'condition
Dim TimerReplacementThrd As Threading.Thread
How to start the TimerReplacement
TimerReplacementThrd = New Threading.Thread(AddressOf TimerReplacement)
TimerReplacementThrd.IsBackground = True
TimerReplacementThrd.Start()
When your condition is met do this
doit.Set()
When closing the program or no longer need to monitor, do this
isrun.Reset()
doit.Set()
TimerReplacementThrd.Join()