Timer Question

General
1

Hey guys,

I’m working on testing one of my apps on a fairly low end Windows 8.1 laptop and it’s revealing how long some tasks can take. For example, I discover a number of devices using Christian’s Bonjour classes. Once I discover a device, I then start a timer which when it fires sets up where the device will go in my listbox of devices and then starts a process to log into the device which in turn ends up firing more timers to get information from the device, etc.

The timers that fire when a device is discovered all have a period of 0. Yet, some of these timers literally take seconds, before they fire! I’ve been experimenting with this by checking the time in microseconds between spots in code and from when I set the timer mode to single and when the timer fires, it is not anywhere close to what I thought it would be. Yes, I have a lot going on with a number of different timers firing and a number of things going on in parallel.

I tried threading some of this that didn’t involve the UI, but that made the time even longer! I’m sure on a faster machine all this is better but I’m wondering if that’s any way to speed up the triggering of the timer. It’s almost like the framework was taking one timer, firing it and then working on every additional timer or process spawned by that first one before going to the next.

I figured that each time through the event loop, any necessary timers would be fired one right after each other…

Is what I am seeing normal?

2

[quote=160440:@Jon Ogden]Hey guys,

I’m working on testing one of my apps on a fairly low end Windows 8.1 laptop and it’s revealing how long some tasks can take. For example, I discover a number of devices using Christian’s Bonjour classes. Once I discover a device, I then start a timer which when it fires sets up where the device will go in my listbox of devices and then starts a process to log into the device which in turn ends up firing more timers to get information from the device, etc.

The timers that fire when a device is discovered all have a period of 0. Yet, some of these timers literally take seconds, before they fire! I’ve been experimenting with this by checking the time in microseconds between spots in code and from when I set the timer mode to single and when the timer fires, it is not anywhere close to what I thought it would be. Yes, I have a lot going on with a number of different timers firing and a number of things going on in parallel.

I tried threading some of this that didn’t involve the UI, but that made the time even longer! I’m sure on a faster machine all this is better but I’m wondering if that’s any way to speed up the triggering of the timer. It’s almost like the framework was taking one timer, firing it and then working on every additional timer or process spawned by that first one before going to the next.

I figured that each time through the event loop, any necessary timers would be fired one right after each other…

Is what I am seeing normal?[/quote]

Timers are not bullet proof in terms of response, since they have to wait until an event is over before firing. I found that some time ago with a while wend that was holding timers.

I never used MBS Bonjour on Windows, but especially on slow PCs, I remember peripheral discovery to be quite slow. Would it not be an issue with the succession of calls to the class along the discovery ?

I guess you have a loop that goes from one device to the other. What if when you start your timer Bonjour has already started an event looking for a device, effectively holding the timer until it is finished ? Maybe you could get your timer to fire by holding the discovery loop as soon as a device is found, launch the timer, and restart the discovery loop in the timer event ? A flag probably can suffice.

Just an idea… I have no way to try. No slow PC here :wink:

3

I’m not sure if you have used Christian’s Bonjour classes or not (Mac or Windows), but the way it works is there’s too classes used - a discovery class which discovers the devices based on their service type and a resolution class (I call these “lookups”) which handles resolving the discovered name to an IP address.

So since all the devices I am using have the same service type, I create one discovery object. But then each device that is discovered gets its own lookup object. I store the lookups in a dictionary. The lookup objects have an event which I then use to trigger the timer that calls the DNS resolution method, etc. The timer is needed here as the DNS resolution itself takes about a second and without it, the UI freezes and gets ugly. Originally I had all this in threads, but based on Kem’s recommendations I’ve moved away from threading and replaced things with timers. And in my latest test, threading actually took quite a bit longer - it didn’t help because I still need to fire a timer to update the UI.

Then once the timer fires to resolve the IP, I then raise an event that is handled in the container control that contains all my UI controls. In this case, I check to see if the device I am discovering already exists in my list of devices. If it doesn’t I create a new device (it has its own code object) and then start other timers to do the connection to the device, etc.

There really is no “loop” for discovery that I can control as that is all inside Christian’s code. It’s an asynchronous process that runs and I just handle the discovery of devices as they come along.

My code works and it seems pretty solid but I’m just trying to speed things up as much as possible.

I’m just surprised at how long it is actually taking some of the timers to fire. Yes, the discovery is somewhat slow but not that bad once Bonjour starts seeing devices.

It’s too bad there’s not a priority flag for timers where you can force one to fire before a different one…

4

Several seconds for a period of zero is an eternity for a computer. Even for Windows (smile). Somethings has to be holding the system down somehow.

You could use one timer instead of several and manage a queue of calls to methods inside it’s action event.

5

I swear, one of these days we’re going to see a Xojo app that consists of 8-10 separate apps that are run/managed by one master app, to truly handle all the timer/thread issues (UI updating and other things) that Xojo just doesn’t seem to manage well under the hood.

This isn’t a critique of Xojo Corp., I’m just saying that if there was a way to get consistent results, there would be example code posted and that would be the end of it. But there’s not. I “KNOW” it’s been said “threading is hard” etc. etc. but the most many people want to do is to update the UI expediently (that is before the users notices a lag).

6

The OP is not about Threads.

This has been solved, see: Task.

7

Well, if your main thread is busy, there may be no time to fire timers.

8

What Xojo was this introduced in?

9

It was in the examples of 2013R3.3, and the files are dated Aug 23, 2013.

10

My suspicion too : you might have an event that’s being handled that’s sitting in a loop?

Remember: Timers can only fire when the event loop is idle. Stated another way: Events do not share time with other events: an event must exit before the next event can start.