Memory Issue with User Event

[Chris O]

Good afternoon!

I have a LabVIEW class that contains as a property a reference to a User Event with a boolean data type. A unique User Event is created for each instance of my class. I create anywhere from 50-500 instances of my class and I generate the user event between one and 50 times a second (It's different for each object). The problem is, when I do this, I get an incredible amount of memory increase; on the order of 400KB to 3MB per second. The lower half of the attachment shows the method for firing the user event. I added a property to my class called "Silent" which turns off the sending of the User Event and when I set my objects to silent, there is also no memory increase. None of the user events have anything registered for them, so there isn't a difference with some other action happening. I can't figure out why in this situation, there is a memory increase. As a comparison, I made anther VI (top half of attachment) that creates 1000 of the same type of User Event, puts them in a cluster and then gets a data value reference and generates events for all of them at 100Hz. Using that VI, there is no memory increase. I have other classes that I also pass around by DVR and they also have User Events, but I have never seen this issue. Anyone have any suggestions, or obvious problems with my code?

Thanks,

Chris O

[Ton Plomp]

What's the type of your class?

Is it a by-ref or by-value class?

A by value class could explain this.

Do you see the same amount of memory usage if you use a queue?

For such intensive taskes (up to 2500 events per second) I would prefer a queue loop.

Ton

[Chris O]

What's the type of your class?

Is it a by-ref or by-value class?

A by value class could explain this.

Do you see the same amount of memory usage if you use a queue?

For such intensive taskes (up to 2500 events per second) I would prefer a queue loop.

Ton

The class has 14 properties. There are 5 strings, 2 timestamps, 4 doubles, 2 booleans, and a boolean type user event ref. My "constructor" method creates my object and then gets a data value reference. The reference is how the objects are accessed, and all my methods use the DVR.

I don't believe accessing the data is the issue. I see no memory, or for that matter CPU, issues when I am updating my objects. Running at 2500 updates a second (which is above real-world levels), I only have about a 1% CPU utilization increase. I can even torture-test my system with 10,000 instances updating at 100Hz and while I get a large initial memory hit and the CPU load from that many updates, there is no memory increase while running. It's only when I enable the event generation that I see the memory increase.

I tried to duplicate the setup, albeit simply, with my sample. The only difference I see is that I'm not firing the event from inside a method. The thing that I'm confused about is the ONLY thing I have to change to get the memory issue is to enable the firing of the event. If you look at the lower-half of the original attachment, the Event Ref is being read whether the Silent property is TRUE or FALSE.

Also, when I used the profiler to see where this problem was happening, none of my VIs showed more than 5.7k of max memory use, even though I ran the profiler while memory use was increased by 50MB.

Oh, I forgot to mention I'm using LabVIEW 2009 32bit. I don't remember if I have 2009.1 installed or not. I do my development on a 64bit Vista PC. We usually deploy to 32bit XP systems. I haven't put this into an executable or tried it on another system.

[shoneill]

I think your problem is almost expected behaviour.

You say up to 500 instances at 50 times a second are being fired.

This makes 25000 Events per second. Each user event is a minimum of 17 Bytes (See picture attached) and all events are stored in a queue. This means that if you do not PROCESS the events, then they are being stored in memory at a rate of 500 instances x 50 Hertz x 17 Bytes = 425kB per second. ALL of these events are then available to an event handler (which can lead to a huge backlog of events if not handled quickly enough).

It doesn't explain why you would be seeing 3MB/s increases. I'm also not sure if a User event which has not been registered should allocate memory at all either. I would have thought it would not allocate memory since with nothing to process it, it is falling on deaf ears so to speak.

Can anyone clear up on whether a non-registered Event should be stored in memory?

Shane

[mje]

I would expect that if there are no registrations for an event (be it dynamic or static), firing it is essentially a no-operation? At least that's how it should be, there's no use queuing an event if there's nothing to signal it with...

Edited April 19, 2010 by mje

[Chris O]

I think your problem is almost expected behaviour.

You say up to 500 instances at 50 times a second are being fired.

This makes 25000 Events per second.  Each user event is a minimum of 17 Bytes (See picture attached) and all events are stored in a queue.  This means that if you do not PROCESS the events, then they are being stored in memory at a rate of 500 instances x 50 Hertz x 17 Bytes = 425kB per second.  ALL of these events are then available to an event handler (which can lead to a huge backlog of events if not handled quickly enough).

It doesn't explain why you would be seeing 3MB/s increases.  I'm also not sure if a User event which has not been registered should allocate memory at all either.  I would have thought it would not allocate memory since with nothing to process it, it is falling on deaf ears so to speak.

Can anyone clear up on whether a non-registered Event should be stored in memory?

Shane

Two things to note:

1. The events aren't registered anywhere. They are there for future use in this framework. Even when they are used, it's only one or two at a time. Also, most are updated at 1Hz. Only a few are updated at 20Hz, and none are faster than that.

2. The second example registers more events and fires them more rapidly than I would ever use my class for and it shows no memory increase.

[shoneill]

Two things to note:

1. The events aren't registered anywhere. They are there for future use in this framework. Even when they are used, it's only one or two at a time. Also, most are updated at 1Hz. Only a few are updated at 20Hz, and none are faster than that.

2. The second example registers more events and fires them more rapidly than I would ever use my class for and it shows no memory increase.

Just wanted to make sure you were aware of the queuing nature of Events and also the extra 16 Bytes baggage each and every event comes with.

I'm also of the opinion that firing a non-registered Event (while not quite being a No-op - it needs to check if it has been registered) whould create minimal overhead and definitely not cause an increase in memory usage.

I personally use Events a lot and find them to be cool, but could be much improved. Performance versus Queues is one thing which kind of annoys me. I've yet to hear a good reason WHY receiving an event is inherently slower than reading from a Queue for the same data size.

Add to this various timing issues and I'd make a suggestion on the idea exchange but I'm pretty sure it'd get no support.....

Shane.

[Chris O]

Just wanted to make sure you were aware of the queuing nature of Events and also the extra 16 Bytes baggage each and every event comes with.

I'm also of the opinion that firing a non-registered Event (while not quite being a No-op - it needs to check if it has been registered) whould create minimal overhead and definitely not cause an increase in memory usage.

I personally use Events a lot and find them to be cool, but could be much improved. Performance versus Queues is one thing which kind of annoys me. I've yet to hear a good reason WHY receiving an event is inherently slower than reading from a Queue for the same data size.

Add to this various timing issues and I'd make a suggestion on the idea exchange but I'm pretty sure it'd get no support.....

Shane.

Thanks for that I am aware of the "background queue" that's created when an event is registered for. I use queues and events a lot in my programs, but I have just never seen a situation where such a memory increase occurred. I tend to stay away from passing any sizable data via events anyway. For large data sets, I almost always use queues. I have been experimenting with Data Value References lately, but haven't converted over any of my old code. My confusion is that in every other attempt to recreate this particular issue, there has been no similar behavior. I can strip down my code to nothing (there's not much to it now!) and still, the only thing that seems to impact the memory increase is the firing of the events.

I'd love to sheepishly admit there was something that was responding to the events and opening a reference and not closing it, but there isn't any thing like that (...goes to double-check... nope)

Any chance there's something funky going on with an event fired inside an In-Place Element structure from a DVR in a sub-vi?

[Chris O]

I'd love to sheepishly admit there was something that was responding to the events and opening a reference and not closing it, but there isn't any thing like that (...goes to double-check... nope)

So... yeah... I have to sheepishly admit...

Maybe I should have triple-checked. I found a place where I was actually registering for the event. It was a way to receive verification from the higher level VI that it had received the request for registration from this object. I pulled a goof and wasn't de-registering for the event. I found it when I was working backwards from the end of the process chain. That's why I didn't find it until the end. *sigh

The good news is that the system works fine now. Thank you all for your time; I appreciate the help and I'm relieved it turned out to be such a little thing.