maximum size of an event structure

[Bauch@Berkeley]

I have just a short question about the maximum size of a event structure, and did not found it yet in the forum.

I have an event case with 35 event cases. How many are allowed, what is recommended and is there a huge loss of performance by seizing it up?

Thx for answer

[chrisger]

hi there

"How many are allowed"

   - i don't know, but i'm sure more than you will need

"what is recommended "

   - if there are several events calling the same code consider to call the code in a case structure and pass an enum from the event cases to the case selector. this will minimize your code. you can pass the enums from the event cases to a queue and deque it in a parallel loop. the code of the event cases will then be executed in that parallel loop.

"is there a huge loss of performance by seizing it up?"

   - i've seen an app with about 250 controls using events. the app ran without any problems and <5% CPU usage in idle mode 

[Bauch@Berkeley]

so i do not have to care about that. thanks a lot.

[parthabe]

hi Bauch,

Pls find attached an elaborate example for multiple events handled for diff controls.

I think this should be sufficient for clearing your doubts reg event structures.

In fact a simpl ewhile loop with a stop button control will show a CPU usage of 100%, but not an Event structure inside a while loop. It'll at max show upto 10 or 20%, in my experience, and even less most of the times.

It mainly depends upon Ur sys configuration.

Try to add events that have similar operations in the same structure by using the multiple event configuring facility,
as shown in the my attached VI.

Regards,
Partha.

[tst]

---

@parthabe wrote:

In fact a simpl ewhile loop with a stop button control will show a CPU usage of 100%

---

I can't look at your code, but this probably means you didn't place a wait statement inside your loop. When you don't do it, the loop tries to run all the time and takes all the resources it can get. Placing a wait inside the loop (usually even a 1 ms wait) will decrease this significantly.

[Ben]

tst wrote "this probably means you didn't place a wait statement inside your loop..."

My thought exactly.

BTW, I have done 86 event cases (with each event case configured to support from 1-6 events) without issue.

If some aspect of your app must perform an operation that takes a long time (i.e. longer than you want to wait before hitting the next button) then a producer consumer design can be used to off-load the heavy lifting from the event structure.

Ben

[Ray.R]

I totally agree with tst.

Definitely place a delay (even as small as 1ms) within a while loop. 

[parthabe]

hi all masters,

Thank you very much for broadening my vision reg while loop programming.

I'm relatively new to LV, programming for 2 yrs only.

tst, I really wonder if Ur LV knowledge is equal to the horizon and the zenith... ?!

Regards,
Partha.

[DFGray]

The only caveat I can think of for adding lots of events to an event structure is ease of maintenance.  I have run into significant GUI slowdowns (development time, not run time) when you start stacking lots of code.  Newer versions of LV will be better than old ones and faster processors have made this almost unnoticeable.  Producer-consumer architectures do help.  I almost always regret it when I don't use one.

[Jason King]

As far as run-time performance is concerned, the number of event cases in an event structure should have no noticeable effect.  Worst-case scenario, when the event structure is woken up due to an event occuring in the system, it does a linear search through the list of event cases to figure out which event-handling diagram matches the event that it pulled off the queue.  These tests are pretty quick (3-4 comparisons per event-handling diagram) so I can't imagine it really would have any effect on performance.  However, this does tell you that if you want to squeeze every ounce of performance out of your event-handling code, make sure the most frequently run event-handling diagram is the first one in the list.

The only performance issue I could see arising is what Damien mentioned - at edit time, it may take longer to make edits to the event structure (eg adding new event cases, changing the events a given diagram is associated with).  I don't know that I've seen any issues because of this (the largest application I've written has an event structure 40 different event-handling cases), but I think this is where any potential performance issues reside.

Hope this helps.

J