www.jfree.org

I am using JFreeChart to do some backtesting in the Forex market. I have a csv sheet containing 1 years worth of 1 minute data. In all about 370,825 entries. I have loaded this data into a time series chart(obviously using Minute() for the time period), but the performance is horrible. I profiled my application and here are my results that use up all my memory:

org.jfree.date.SpreadsheetDate ->1,250,144 B
org.jfree.data.time.TimeSeriesDataItem ->625,840 B
org.jfree.data.time.Hour ->624,992 B
org.jfree.data.time.Day ->623,760 B
org.jfree.data.time.Minute ->623,648 B

This is just one chart. I need two more, but there is no way this will be possible. Is there anyway to reuse the objects needed for the data? As the subject title asked... Is JFreeChart a practical answer for this kind of application?

Thanks,
Scott

On a one-minute interval with 10 hours of data per day, 250 days/year that's about 150,000 points on the x-axis. My screen has 1280 pixels across the way so that would mean I would cram about 120 points into each pixel.

Put it another way, you only need to plot points every two hours over the course of a year to completely use the full resolution of the screen - in practice, for a year chart, each day's closing price would be perfectly adequate.

So basically, I'm saying that obviously the thing doesn't work because you are grossly overdoing the resolution.

Then again, maybe I'm mistaken - how big, exactly, is your screen?

So basically, I'm saying that obviously the thing doesn't work because you are grossly overdoing the resolution.

Actually it does work. Regardless of resolution, my performance is bad because of how much data objects I am creating (as seen from my previous post).

But I did do an experiment to test your little theory. I did a one month chart on my computer. I have two 20 inch monitors (1680x1050). I profiled each of the following: The first part I made my chart screen about half the size of one monitor and the second part I utilized both screens (3360) and the results.... there was absolutely nothing different. The performance and memory usage was exactly the same.

Thanks you for your response, but that's really not the answer to my question.

The TimeSeries/TimeSeriesCollection classes are very flexible, but a little heavy on memory usage. In JFreeChart 1.0.2, a more lightweight dataset (org.jfree.data.xy.DefaultXYDataset) which uses a double[][] array as the underlying storage, was added. Maybe that will help you here. For the x-values, just use the "milliseconds since 1-Jan-1970" encoding defined by java.util.Date.

Thank you David! I will give it a shot and see if that'll work for me

Thanks

I don't think you understand what I'm saying...

Your problem is that your data objects are too large and take too long to create - correct?

My point is that you can't see all the information in your charts anyway so you might as well make them smaller, then they'll be quicker to generate. A one-year chart with data points every minute has over a hundred data points in every pixel - so that's pointless resolution. In other words, you could reduce the number of points on the x-axis by a factor of 100 and teh chart would look *exactly* the same on the screen, but it would consume only 1% of the memory and fill 100 times faster...

how could I reduce the number of points on the x-axis by a factor of 100..in TimeSeriesCollection..
Kind request for reply

by retrieving less data and thus putting less data into the collection...

In our system I can simply tell the engine to give me points at specified intervals (minute, hour, day, for example) and I get a filtered set as a result.
If your system doesn't have something like that, maybe it's time to add it

Even if I take little data...the distance between one point and other point is more.. the point is ...I have to set some method in time series object or time series collection object.....
Please provide some pointer....

filter the data between retrieval and insertion in the data to be plotted...

370,825 entries is no problem for QN Plot:

//quies.net/java/math/plot/

the problem isn't the number of points per se but the memory and CPU cycles needed to extract and store them...

Using another product you signed up here to spam about isn't going to help that.

Eazy man! What's that attitude for? It's free software.

You misunderstood. My implementation uses QN CSV and is able to parse and render 420,000 coordinates within 2 seconds on a 2.4GHz Xeon.