async timer slows operation down

[umquat]

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

[menchar]

One thought I have is to ask what you're doing in CompactDataControl. You're calling it from the async timer thread, rather than from (most likely) the main thread as is the case with a traditional timer callback.  So depending upon what is happening in CompactDataControl, you may be looking at thread scheduling issues - everything is on the same thread with the regular timer, but not with the async timer.

You shouldn't be manipulating the GUI from CompacDataControl, as it's running on the asyn timer thread.  It could be that it sortof works if you do, but you're only supposed to manipulate the GUI from the thread that loaded the form.  This is a common restriction, it might be that NI fixed up the async thread to be able to do things with the GUI but they'd have to tell us, I've never heard that you could.

[umquat]

What I cant get my head around, is that I've set timing test points through the code - ie checking the time before and after a function. Some of these functions, just do data manipulation, and yet where ever I put these check points the code runs slower than it used to. Its not that a specific part of the code is significantly slower.... its all of it. 

I'm thinking I might have to take a look at the overall design, but as an aside, is there any way to use conventional timers, without the problems associated with them?

[menchar]

What are you doing to get the elapsed time measurement?  Maybe that's what's slowing it down.  There's a timer built into the Pentiums that you can use to do high res elapsed time measurements, I think there's little overhead to using it, I've got code for it somewhere, I think there's a thread on this site on how to use it from CVI.  I think it's called the performance  counter.

I tend to use async timers and I design the application to avoid access to the GUI from the async callback.  You can decouple measurement tasks (or any "worker" or data-crunching task) from the GUI by putting these tasks on an async timer callback, then have the asyn callback post the measurement data (or result) into a global (top-level variable in C) where a regular timer callback picks it up and puts it onto the GUI.  This way, you get the measurement/calculation made with the timing accuracy you want or need, and the variance is put into the GUI update loop, not the measurement loop.

[umquat]

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.

[menchar]

I don't think you can immunize a standard timer from the window resize/move - this is an old issue with windows - used to be you could grab a window by the title bar and swirl it around and you could see the CPU usage go to 100% and everything come to a stop.

I think I've done GUI stuff from an async thread and it seemed to work - but I wouldn't want to rely on it without knowing more.

I've done several applications using async and regular timers the way I mentioned - it works great so long as you don't care if the GUI update rate varies a bit.

[umquat · Accepted solution]

No a bit of GUI lag, isnt a problem as long as the data being captured, is done so on a regular basis.... The biggest problem that is currently experienced, are things like spikes in data.... flat lines in graphs because the time might have changed but the data hasnt since the last plotted point, because the plotting is done on the fly, instead of from a data buffer. There are a few historical problems with this software, and I'm pretty sure I'll be working on them for some time to come, despite of the fact that I've been working on it on and off for at least 3 years now!!

Thanks for the input... you've answered my question - not in the way I had hoped you might, but to be honest probably in the way I expected - ie no 5 minute solution!