I use timer to refresh my Zedgraph as i need to update new data, and i notice
that after running for a while (about 10 minutes) my system is getting slower
and slower as the RAM being used up.
What is the way to free up the zedgraph memory usage?
Please help
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i've got the same problem. I am drawing 4 curves with a new value every 50
milliseconds for each curve. I am using RollingPointPairList(12000), and after
about 2 Minutes the dynamic scrolling gets very slow, no more smooth, graph
begins zu flicker. After 3-4 minutes AxisChange() results in an Exception,
application crashes.
Is this caused by my RollingPointPairLists getting fuller and fuller?
Does ZedGraph draw ALL values when calling Invalidate(), even if i only see a
few ones?
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, handling big amounts of data is a real problem in ZG...
IMHO, 12000 of points is a quite big number for a data container capacity...
Do you really need such precision/history? Maybe try to optimize your code,
display only relevant points etc... There are many techniques to do so...
What kind of exception do you get? Could you paste stack trace of this
exception?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use a pplist to display ~ 3700 points pretty much as fast as screen refresh
rates allow. The algorithm for displays after the first is: clearPPlist,
display, loadPPlist, call the display routines. In addition, this graph
displays alert conditions when data is outside of nominal.
To trend this activity (i.e. instrument monitoring) over time, I build a
separate graph. This graph rescales the time axis (potentially) with each
display. Note that this graph does not use all the points as described in the
previous graph. Since it's trend over time, averaging is used (tha.t's a gross
simplification but represents the general idea)
We've run this design, taking several million measurements in total, up to 36
hours with no performance degradation or apparent memory leaks.
This design allows for both real time data capture and trending. It's actually
driven more by user requirement. Not sure how capturing all the points you
describe would have visual meaning for the end user. (That's the main reason
we capture alert condtions on our real time graph.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use timer to refresh my Zedgraph as i need to update new data, and i notice
that after running for a while (about 10 minutes) my system is getting slower
and slower as the RAM being used up.
What is the way to free up the zedgraph memory usage?
Please help
Hey,
i've got the same problem. I am drawing 4 curves with a new value every 50
milliseconds for each curve. I am using RollingPointPairList(12000), and after
about 2 Minutes the dynamic scrolling gets very slow, no more smooth, graph
begins zu flicker. After 3-4 minutes AxisChange() results in an Exception,
application crashes.
Is this caused by my RollingPointPairLists getting fuller and fuller?
Does ZedGraph draw ALL values when calling Invalidate(), even if i only see a
few ones?
Thanks!
Yes, handling big amounts of data is a real problem in ZG...
IMHO, 12000 of points is a quite big number for a data container capacity...
Do you really need such precision/history? Maybe try to optimize your code,
display only relevant points etc... There are many techniques to do so...
What kind of exception do you get? Could you paste stack trace of this
exception?
I use a pplist to display ~ 3700 points pretty much as fast as screen refresh
rates allow. The algorithm for displays after the first is: clearPPlist,
display, loadPPlist, call the display routines. In addition, this graph
displays alert conditions when data is outside of nominal.
To trend this activity (i.e. instrument monitoring) over time, I build a
separate graph. This graph rescales the time axis (potentially) with each
display. Note that this graph does not use all the points as described in the
previous graph. Since it's trend over time, averaging is used (tha.t's a gross
simplification but represents the general idea)
We've run this design, taking several million measurements in total, up to 36
hours with no performance degradation or apparent memory leaks.
This design allows for both real time data capture and trending. It's actually
driven more by user requirement. Not sure how capturing all the points you
describe would have visual meaning for the end user. (That's the main reason
we capture alert condtions on our real time graph.)