Performance of Line and Point series

[Andrew FT]

Hello,

We are experiencing the following performance issue with the ActiveX version of TChart Pro:

General symptom: Line and point charts seem to render slowly after adding data programmatically with AddArray() or even FillSampleValues().

Observation: Rendering speed seems to increase by 3-10 times after using the chart editor GUI to change the series type to the same type. After this, adding or modifying data programmatically causes the rendering performance to drop back to 3-10x slower.

The VS2005 C# project I posted in the teechart7.activex newsgroup demonstrates this as follows:

Run the project, click on the "Add Points" button to add a 2D Point series with 25,000 points.
->Rendering timer shows ~1500 ms

Click "Show Editor", change series type to Point
->Rendering timer shows ~150 ms

Click on the "Add Points" button to add another series
->Rendering timer shows ~1700 ms

Changing the series type programmatically does not show this improvement in performance.

Any ideas would be much appreciated!

Thanks,

Andrew Vorozcovs
Software Engineer
Fiber Optic Systems Technology Inc.
4580 Dufferin Street, Suite 402, Toronto, ON Canada M3H5Y2
Tel: (416) 665 2288
Fax: (416) 665-0494

[Narcís]

Hi Andrew,

We don't see any abnormal behaviour in your project. As more series and points are drawn the more time it takes the chart to be drawn. We don't think this performance can be improved much.

[Andrew FT]

Hello Narcis,

Thank you for your reply. Can you please confirm that you are getting similar timing measurements to what I have posted?

What I am pointing out is, the time to draw the exact same chart can vary by up to ten times. It seems that going into the editor and doing essentially nothing (changing the series type to its current value) results in some sort of internal optimization, resulting in the chart rendering much faster. (Now, it is clear that this is not in fact a null operation, since the series seems to be getting cloned internally, showing up as a secondary series flashing briefly on the screen.)

We regularly work with multiple long series in point mode, and this slowdown is very frustrating, especially since it is obvious that TChart indeed *can* render things quickly. 1.5 seconds for 25,000 unshaded points is very slow, while 150 ms seems appropriate.

Thanks again for looking into this,
Andrew Vorozcovs

[Andrew FT]

Hello Steema,

Are you able to reproduce the issue? Please let me know.

Thanks,

Andrew Vorozcovs

[Andrew FT]

Hi guys,

Is anyone looking into this? Are you getting 1500 ms for the original series in the demo program?

Regards,
Andrew Vorozcovs

[Pep]

Hi Andrew,

sorry for delay. Yes, we're trying to find which could be the cause of it. We'll back to you with the results as soon as possible.

[Andrew FT]

Hi Andrew,

sorry for delay. Yes, we're trying to find which could be the cause of it. We'll back to you with the results as soon as possible.

Hi guys - any progress on this?

Thanks,
Andrew Vorozcovs

[Narcís]

Hi Andrew,

Sorry for the delayed reply. We are currently working on the issue. We will get back to you when we have further news.

Thanks for your patience.

[Marc]

Hello Andrew,

The difference in time is caused because when the Point Series is added via the interface, AddSeries method, a link is made for the Series to the OnGetSeriesPointer event that may be used in the container environment to modify the Series Pointer style for each point. When the Series is added via the Editor that link is not made so no Callback code in the application will/can affect the PointerStyle of that Series.

The time lag that is caused checking if the container has set any event is the differentiating factor affecting the time of the runtime and editor added Series. The delay is in the hands of the COM calls and there is little we can do to improve it unless we deactivate the call to the Series events completely.

The PointSeries time lag is a result of the check for the OnGetSeriesPointer event. For a FastLineSeries no such callback exists and for that reason (and other performance optimisations) your example project made with FastLine is several times faster. If many points are involved, for performance and legibility we recommend use of the FastLine Series if possible.

Regards,
Marc Meumann

[Andrew FT]

Hello Marc,

First of all, I appreciate your clear and detailed answer. Now, a couple of comments:

1. We do know and love the FastLine series. However, for many scientific applications, such as correlation (XY) plots, the FastLine series is completely unsuitable. Also, even for signal vs. time plots if the data has large gaps in it, a FastLine series will display misleading straight lines in the blank areas.

2. As you can see, the difference in speed is ten-fold. I think the amount of effort needed to rectify this is quite small compared to the benefit. Also, performance is definitely a very big deal for us for business reasons.

My humble suggestions:

I can see two simple ways to fix this:

1. Very quick but not particularly elegant: Add a boolean switch to the Series interface which would select whether to execute the OnGetSeriesPointer callback. Problem with this solution: violates the "once and only once" principle, i.e. someone not aware of the switch might set the callback and wonder why it is not being called.

2. Determine if the callback needs to be called only once, not for each point, and cache this information in a boolean variable. I know that the slow callback is currently done per-point, since the slowdown scales with the number of points to be rendered. I don't imagine you need to support people dynamically adding and removing callbacks as rendering is progressing (let me know if I am wrong!).

I don't have access to the source code, but I hypothesize that code similar to this exists in the rendering loop (using C#-ish pseudocode here):

Code: Select all

foreach (Point p in points)
{
	...   
	if (VerySlowCOMCall_IsCallBackDefined("OnGetSeriesPointer"))	// Doesn't need to be done per-point
	{
		DoComCallBack("OnGetSeriesPointer", args);	
	}
   ...plot the point...
}

I suggest the following modification:

Code: Select all

bool do_OnGetSeriesPointer_callback = VerySlowCOMCall_IsCallBackDefined("OnGetSeriesPointer");

foreach (Point p in points)
{
	...   
	if (do_OnGetSeriesPointer_callback)	// No function call, extremely fast!
	{
		DoComCallBack("OnGetSeriesPointer", args);
	}
	...plot the point...
}

Please let me know whether you think that my suggestion will work and if you think it is realistic that this change will be made.

Sincerely,

Andrew Vorozcovs

[Marc]

Hello Andrew,

Thanks for your comments. Options are being looked at along the lines of your suggestions. I'll post to this thread with an update.

Regards,
Marc

[Pep]

Hi Andrew,

finally, we have added a new property for IPointSeries (boolean FastPoint) which allows to desactive the OnGetSeriesPointer callback. This increases the speed noticeably.
This property will be available for the next maintenance release v7.014 which will be posted on our web site soon (in a few weeks), but if you need urgently let me know an email account where I can send the new ocx directly to you.

[Andrew FT]

Thanks a lot, guys!

Pep: I will PM you my email address (to avoid spam).

[John P. Francis]

Could I get a copy?

[Pep]

Hi John,

I've just posted an Update version (which includes this additions) on our web site (at the private customers download page).