event structure performance

[aartjan]

Hello again everyone,
I am curious about the performance implications of event structures. Not so much GUI handling, but handling user events, while running in sub-vi's, receiving some data from other VI's through the event registration refnum. I used to do this with queues and I know queues are extremely fast. Now I am tinkering on a nice setup with events, and I am hoping that events don't take too much of a performance hit.
Could it be that an event node always runs in the UI thread, or will it start doing so as soon as front panel events are specified? Will it run in the UI thread when the panel is closed or minimized?
Thanks for your input!

[Jason King]

I think you will find the performance of events in general, specifically user-defined events, to be quite sufficient. I forget the numbers we ran when we were testing the performance, but I would not worry about any noticeable performance hit versus queues. If you're only using user-defined events there is no reason we'd require anything to run in the UI thread when handling the events.  Obviously if you're handling user interaction, we need to switch to the UI thread for some things.

J

[shoneill]

Jason,

I'm fascinated by the following deliciously vague comment

"Obviously if you're handling user interaction, we need to switch to the UI thread for some things."
Under what consitions does an event structure require the UI thread?  Do all events based on front panel objects run in the UI thread?  This is an assumption I've long made.  If not, then there's something else I need to look out for in the future.......

Please note I use LV 6.1, so I don't have user events yet...

Shane.

Message Edited by shoneill on 08-04-2006 08:38 AM

[aartjan]

I am suprised to be getting stars for my question. Sure, maybe someone thinks it is a brilliant question, feel free to reward that. I do not appreciate someone giving me 1 star, though. It is a very relevant and legit question to be posted here.

[Jason King]

Shane: There is nothing specific about the event structure that requires the event-handling case to run in the UI thread.  In fact, there is not any event that will force it to run in the UI thread. However, what you place in the event-handling diagram can certainly influence what thread it runs in (property nodes, invoke nodes, etc).

Most of the code behind the implementation of events and the event structure can run in any thread - access to some data is protected by mutexes, but this is a lot lighter-weight then requiring a thread switch.  Any actual processing of user interaction, however - either looking at user interaction to determine which events to generate or finishing processing a filter event after the event structure has had a chance to discard it or modify any of the event details - requires the UI thread.  In the case of the filter event, I'm fairly certain that the event structure will not complete execution until after the thread switch is made.  In the case of notify events or user-defined events, this thread switch isn't necessary.

Is that the kind of information you were looking for?

J

[shoneill]

Jason,

Thanks for the clarification.

Seems like I've been assuming too much about thread behaviour in LV.  I always assumed that events raised by controls or indicators (i.e. "value changed") ran in the UI thread as they also provide a reference to the control / indicator within the event structure.  So now I presume that if I don't make use of any property nodes, indicators or control references then the code is free to run in whatever thread it's happy with?

Up until now I've always placed the terminal of any controls I'm monitoring via "Value changed" in the actual event structure so that things like booleans will behave as expected according to their mechanical action (being "read" as the event is being fired).  Does this force the event structure into the UI thread?

Is there any way to have a boolean mechanical action react to a "value changed" event without forcing the event case into the UI thread?  I suppose not, but I'm then interested in the accepted way to get around this "problem".  I could imagine a dedicated loop to simply read the controls which can be fired via event structure.  This seems to be getting very complicated for what must be a relatively easy solution.

If I'm missing the big picture here, please let me know.  It happens quite a lot.

Shane.

[aartjan]

It's definitly the kind of answer I was looking for! Thanks!
Event structures are just immensly versatile and I find myself (ab)using it for ever more ways of programming, and not just for user interfaces. It is good to know that an event structure is also fast enough for it.

[Jason King]

Aart-Jan: I'm glad you got the answer to your question.  I agree that events allow for a lot more flexibility.

Shane:  Pretty much anything you do with the reference to a control or indicator will cause a switch to the UI thread (property nodes, invoke nodes, etc).  However, if you don't use those, just the presence of the reference will not affect which thread the event structure executes in.  Your summary is correct - the ES is free to execute in whatever thread so long as you don't use a node that requires the UI thread.

Reading from or writing to a front panel terminal or local variable does not cause the diagram to run in the UI thread.  The diagram has its own copy of the data and does not require a switch to write to or read from it. However, if you use a property node to get/set the value of a control or indicator it will switch to the UI thread.

I'm not sure about your last question, as I'm not sure I full understand. Can you elaborate some more?

Thanks.

J

[LemonOE]

In fact, here I encoutered some performance decrease with user event in event structue.

I use some signal detection in one loop and send a sync event to another VI to sync the snaping of camera.

I found the camer always delay about 50ms to 200ms as the program running for some time.

than I use queue to send the signal detection information and set a independet queue dealling loop in the second VI but not event structure, it seems work better.

[SteveChandler]

You are reawakening a pretty old thread but anyway.. I don't know if an event structure will respond faster than a queue but they are both much faster than 50 to 200mS. The problem is elsewhere. Do you mean that you moved code out of the event structure to another loop and the UI is more responsive? That is to be expected but doesn't really have anything to do with the performance of the event structure vs the queue. It is just that the real work has been moved out of the UI processing loop. The code in the event structure has to complete before the event structure can respond to another event. That can be 50mS or 50 years.