StartTimer slows down more times it is used.

[Bugala]

Example code:

Code: Select all

StartTimer(0)
For n=1 To 100000
	StartTimer(n)
	If n=20000 Or n=40000 Or n=60000 Or n=80000 Or n=100000 Then DebugPrint(GetTimer(0))
Next
DebugPrint("done")

result:
1598
8105
19074
34303
54059
done


Is this supposed to be this way?

I did this test since I am making an Audio Organizer which has files that need to be double-clicked. To check the double-click, I am thinking of starting a timer each time for each file, which means that when using it to look through thousands of files, there could be quite a lot of Timers existing, as I didn't plan on stopping them, but I guess I will stop them after all.

[Flinx]

Maybe a better way is to use only one timer, hold the time of the first click in a global variable and check the difference at each next click.

[jPV]

Yeah, really, don't leak resources like that. Just use one timer and stop/reset it after double click has happened or it has elapsed longer than the double click time. Users aren't going to do simultaneous double-clicks in different places, because usually they only have one mouse.

[Bugala]

It was a matter of independence why I wanted to start a new timer all the time, not needing to rely on anything outside, but due to slowdown I am making a system with just one timer.

Also since I think I once asked about timers something and I think Andreas said it is not a problem to start multiples of them, hence was thinking this, otherwise not so good approach.

[plouf]

maybe not a problem, to start many timers

however your code above as i udnerstand it, start thousand of timers and never close them
so at a time should be 100000 timers simultaneously working

depended on internal implementation, maybe be or a not a problem, as it seems thought in this case "just" slowdown" system

[Bugala]

Found the question I made before: https://forums.hollywood-mal.com/viewto ... mer#p19477

Point was that existing timers don't take CPU cycles, and only very little memory. That is why I was thinking of using them bad way in resource leaking sense to favor the independence of a function.

But seems starting them starts slowing down the "StartTimer()"-command, and although not really that bad at point of 100 000, but it still brings the worry that if someone goes through whole loads of audio files, and even keeps it unclosed for months, this could become a noticeable slowdown at some point. For it has not been that rare for myself to have gone through over 1000 audio files in one session.

[airsoftsoftwair]

Is this supposed to be this way?

Um, well, yeah, of course for every timer you start Hollywood will allocate an object which is stored in a list so that it can be garbage collected and freed at the end. So allocating 100000 timers is the best way to kill the performance by flooding Hollywood's lists with objects. There surely has to be a better way than allocating 100000 timers...