2

I am using ObservableCollection to store information on my CPU Usage and transferring this information to a line chart. the information is updated every second. It is working fine but I realize that this is going to jam up my memory overtime cos it just keeps adding information to the list.

What is the norm in this situation? Do you reset the list after every minute? I feel that would mess up how the chart looks every time it resets. Please advice how I could manage this memory issue swiftly. Thanks.

ObservableCollection<KeyValuePair<double, double>> chart1 = new ObservableCollection<KeyValuePair<double, double>>(); 


chart1.Add(new KeyValuePair<double, double>(DateTime.now, getCurrentCpuUsage()));
kar
  • 3,679
  • 8
  • 37
  • 53

2 Answers2

3

What exactly you should do depends on your requirements.

If you only need to retain a certain amount of data (e.g. 10 minutes or whatever), a bounded queue may be more appropriate than an ObservableCollection. That way, events that are "too old" automatically fall out of the data structure, allowing you to cap memory usage.

If you still want to be able to access older data in the future, you could write the data coming out of the end of the queue to a file or database instead of just dropping it.

For one implementation of a bounded queue see

Limit size of Queue<T> in .NET?

Since you may need an observable bounded queue, here are some notes on how to implement one (fairly straightforward)

Observable Stack and Queue

Bounded Queue Explained

A regular queue is like the line at a checkout stand. People line up (or as the British would say queue up) at the end of the line, and the cashier takes the person at the front of the line. First in, first out. FIFO.

A bounded queue sets a maximum length for the line. For a real-life line, new people would be prevented from joining the line if it is too long. Some bounded queues in software work that way too. The other option to keep the queue length from exceeding a limit is to remove from the front of the queue when the line is too long. In real life that's probably not very fair, but for software algorithms that's sometimes just what you need.

Community
  • 1
  • 1
Eric J.
  • 139,555
  • 58
  • 313
  • 529
  • I looked around and did come across the idea of a bounded queue but was kind of confusing. Trying to grasp the idea with your links. – kar Feb 27 '14 at 18:40
  • Added some explanation to help you with the concept of bounded queue. – Eric J. Feb 27 '14 at 20:14
0

Store as much information as you need and drop (or save to file) the rest.

If you need to store data for very long time spans (more than i.e. 1M of data points) you may try compress data. But figure out your goals and measure performance time/memory usage first.

Alexei Levenkov
  • 94,391
  • 12
  • 114
  • 159
  • At any point of time, I am looking to only store 1 minute of information. I am storing information every sec thus 60 sets of info. – kar Feb 27 '14 at 18:41