postuimessage speed

[DaveC]

Hi,

I am upgrading an application to try and make it process quicker than it already is going.  Currently it is running through a loop N number of times in a teststand sequence, and each time during that loop I make three separate calls to 'postUImessage' to post a message on an external UI that is using my TestStand code as a backend. 

I have put timers in the sequence call and when running my UI I have noticed that it takes approximately 80 ms to make this call to postUImessage.  When this time is multiplied by 3 time (one for each separate call to postUImessage) and run in a loop of 1000 times this adds significant delay to my application.  I have also noticed that this 80 ms hit seems to occur only once if I am calling more than one postUImessage in a row.  However, if I run some code in between the postUImessage calls the initial 80ms hit comes back. 

It seems to me that there is some kind of cache that is saved to speed this postUImessage call up.  My question would be, is this the correct assumption?  And if it is correct, is there a way that I can initialize this cache one time and have it saved so that during my loop of N times I don't have to take the 80ms hit when I call the postUImessage?  If I am incorrect, does anyone know what would be the cause of the 80 ms delay and/or know of a way to get around it?

Thanks!

TestStand Engine 3.1

Windows XP

[JonathanN]

Hi Dave,

I have some comments and questions for you.  First off, that 80 ms timing issue you are seeing isn’t normal. Here is how UIMessages work. 

Each Operator Interface contains a UIMessage handler that continuously monitors events posted from the TestStand engine. How the UIMessage handler is implemented depends on the programming environment.  The UIMessage handler constantly checks the message queue to see if it’s empty or not. If the queue is not empty, it gets the next UIMessage.

There are several areas we can check to see what could be happening.  First off, do you have any type of tracing enabled (Configure >> Station Options).  If so, turn this off and try running your application again.  

That 80 ms won’t be normal unless you have code handling UI messages that take a long time.

Also, PostUIMessage can take longer than expected if you have the synchronous parameter enabled.  The last parameter of PostUIMessage is the synchronous parameter which is a Boolean type. You set this variable to true if you want the method to wait until the operator interface processes the message. You pass a false variable if you want the method to return immediately.  

Also, what type of message are you posting? This could be an issue as well in terms of the timing situation.

Hope this helps!

Best Regards,

[DaveC]

Hi Jonathan,

Thanks for the reply!  I do have tracing enabled on the test stand and I turned it off after reading this e-mail.  Unfortunatly I don't get to play with any hardware to actually test it's effects until monday.  Aside from that I was interested in what you said with how the UIMessageHandler is implemented.  The message handler that I have right now is in VC++ and was not written by me, nor can I easily mess around with modifying the code in there. 

I did, however, put some timers in there the other day and it looks like the message handler function in the VC++ code itself takes only 1 or 2 ms to run.  However, I was wondering if you thought it might be a possibility that the message handler is not checking the queue enough either because the system is getting pushed pretty hard by everything else running (the test machine i have is pretty slow for todays standards p3 800MHz) or maybe even there is a delay that I can look for to see if it was set in the VC++ code that tells the message handler check only once every x number of ms?

For the synchronous parameter I do have it set to false already so that wouldn't be a possibility.  That's what was really confusing because like you mentioned the function is supposed to return immediately if the parameter is set to FALSE, so I couldn't understand where the 80ms was coming from.  Currently to time things I am simply putting two expressions around the PostUIMessage function call. One that sets start = Seconds() before the function, one that sets stop = Seconds() after the function and then i subtract start from stop to get a total time.  Do you think that this is an accurate way to do this or is there a better way?

The type of messages that I am posting are user defined messages to the UI that is the frontend for the teststand sequence.

Message Edited by DaveC on 02-17-2006 10:56 AM

[JonathanN]

Hi Dave,

Have you tried timing posting UIMessages with our shipped operator interfaces? The reason I ask is that if you don't get the same results, then you know that its something you are doing in your own code. Do you know if you are using polling or event-based to get UIMessages from TestStand? In order to enable polling, you must set the UIMessagePollingEnable property to false. 

That system is old and slow and it is likely possible that having a system like this could cause that behavior. You could easily test this by moving to a newer and faster computer and perform some timing calculations there.  You could also try removing and stopping any processes on your current system to free up some CPU memory. 

Hope this helps!

Best Regards,

[DaveC]

Hi Jonathan,

I ported the application to a quicker computer and I tried it using both my custom UI and also with the "C++ using MFC" UI example provided by NI.  In both cases I was able to reach acceptable updated times (~< 2ms) for my application.  I guess the solution is better hardware.  Bah!

Thanks for the help!