Async timer slows operation down

Question

Having previously used asynchronous timers to resolve another problem that I had, I'm now looking at an issue that has got me stumped
Here is a code snippet which has had an asynchronous timer applied
int CVICALLBACK ParentEvent (int reserved, int control, int event, void *callbackData, int eventData1, int eventData2)
static int iInfoFlag = 1;
//If Com Timer event has occurred then:
if (event == EVENT_TIMER_TICK)
SetAsyncTimerAttribute(control,ASYNC_ATTR_ENABLED, 0);
//First, has sonde configuration changed?
if (iSondeConfigure_HasChanged() == YES)
//Re-initialise displays etc, if true
InitialiseSondeSystems(iFloatingPanels);
//Get Sonde data
if (ProgStatus.bComTimerEvent == TRUE)
CompactDataControl (hParentPanel, iInfoFlag, &ProgStatus, NULL);
//If Com events are disabled then set Sonde Info flag for next data
//acquisition sequence
if (ProgStatus.iComEnable != ENABLED)
iInfoFlag = 1;
SetAsyncTimerAttribute(ParentTimer,ASYNC_ATTR_ENABLED, 1);
return(0);
This routine was previously handled by a conventional timer but as these sit at the bottom of the pile when it comes to scheduling, as soon as the interface was manipluated it shut up. The timer in each case is set at 0.1 second, and if the bComTimerEvent flag is set to true, which is controlled by another (currently traditional timer) it goes away and grabs data from an external source. Using traditional timers, I can clock this 'grab the data' timer quite happily at 0.25 seconds. However with the code shown, it wont grab data any faster than about 1.5 seconds. I have timed how long it takes to call and return from CompactDataControl. With traditional timers its about 0.2 seconds, with the code as shown, its about 1.45 seconds.
Any thoughts as to what I've missed or messed up.
Regards
Gavin
Solved!
Go to Solution.

Answer 1

All I'm doing is calling Timer() before and after a particular function, and working out how long it takes... I've done this with both normal, and async callbacks and got significant differences. I think due to the nature of what has been done already, this code will need the same treatment as the last project I worked on that required async timers, which was a complete rewrite from the ground up. What is interesting is that that project does make changes to the GUI based on the async timers, without any obvious performance issues, despite of the fact that elements of the GUI are created in the main thread. However this project is doing an awful lot more, which might in someway explain this.
I'd be interested to know if there is any way you can use traditional timers without the problems of timers stopping, when moving or resizing the GUI - the thing I am try to prevent by using async timers
However I think what youre saying about your use of Async timers for number crunching, and standard timers for GUI update is a good idea, and I'm pretty sure would work for me.