0.9.5, and performance improvements

[Irv Thomae]

Hello David,
You've mentioned in a couple of recent threads that you're aiming for release of 0.9.5 by the end of next week/this month (same thing!)
Since we've often discussed ways to enhance performance, I want to be sure you've noticed my suggested improvement to the render() method of class XYPlot. (Described in my 1-22 posting of the long-promised "DynamicTimeSeriesCollection" class, in the thread of that name. )

A much faster alternative to BasicTimeSeriesCollection, 'DTSC' nevertheless does implements the XYIntervalDataset, DomainInfo, and RangeInfo interfaces. That puts a performance premium on its getX...(), getY...(), getMinimumRangeValue() and getMaximumRangeValue() methods. Your caching suggestion for DomainInfo and RangeInfo, by the way, was very helpful.

A dynamic plot requires synchronization between the thread(s) adding data to it and the thread that will refresh the displayed graph. It was obvious that any method which updates the dataset in real time should be synchronized - meaning that an exclusive lock on the dataset object is obtained before execution.

However, adding the "synchronized" keyword to the getX..() and getY...() methods would have imposed a serious slowdown, since they get called repeatedly whenever the display is updated. The solution is to add a "synchronized (dataset)" block around the loop in XYPlot.render() , so that the get-lock overhead is incurred only once per display refresh, not once for every data point. It's a small change, and will have no detectable effect at all on XYPlot when used with other XYDataset classes that don't have any "synchronized" methods.

Irv Thomae
ISTS/IRIA/Dartmouth College
Hanover, NH (USA)

[David Gilbert]

Hi Irv,

I'll try to get to this before I release 0.9.5, but the whole thread synchronisation thing (which I have been thinking about because it is a problem) gets fairly complex with the combined and overlaid charts. I think you are on the right track with synchronising in the render() method, but it might be necessary to go even one step further out and synchronise somewhere in the chart.draw(...) method...although what you suggest should work fine for regular charts.

Anyway, I'll try to look at your classes more closely in the next day or two...

Regards,

Dave Gilbert

[tmichals]

Overall, what is a percentage of speed increase?

[Irv Thomae]

> Overall, what is a percentage of speed increase?

Percentages are clumsy when there's better than an order of magnitude improvement.
In our application, we're displaying an "impulse plot" of 2 variables, 1440 values of each (i.e., 24 hours x 60 minutes). When new data are appended, the entire plot appears to shift left at once - in other words, the visual impression is as if the entire graph got redrawn at once. And that's _with_ the thread synchronization David and I are discussing here.

An equally important measure of speed is the time required to load and plot a different set of 2 x 1440 datapoints. When I started working with jFreeChart, that change took at least 12 seconds. It now happens in less than a second, from clicking on a change-request Swing element to seeing the new dataset displayed in place of the old. (Some of the speed-up is attributable to the FastXYImpulseRenderer class, which I posted here a couple of months ago.)

Irv Thomae
ISTS/IRIA/Thayer School of Engineering
Dartmouth College
Hanover, NH (USA)

[tmichals]

Yes, I'm having a simlar issue, plotting magnitude data for a given frequency spectrum. XYPlot. But, I'm attempting to draw 2x1401 every 100ms. (can scale this back to 250ms) At this time, this package provides great number of features, but lacking in performance.

I'm thinking of moving to straight swing, but I realld don't think this will keep up? Any comments? Thoughts? Guidance?

[Irv Thomae]

I'd urge you to take a look at the code I posted last week in the message thread titled "DynamicTimeSeriesCollection", and try it out. My timing tests were very crude - (for example, I actually used an old-fashioned mechanical stopwatch) - so I really can't tell you whether it has the speed you require. It might just work, but I can't promise.

Of course, for an application like yours that seems to push the envelope on performance, the best thing about jFreeChart is that being entirely open source, you can with relative ease search for the bottlenecks relevant to your situation, and perhaps fix them.