I know that a sample project will help to reproduce th issue. I'll try, tho it's nested deep into our SCSF project using internal and external proprietary components.

I thought it might be something obvious I missed out on. What are typical scenarios where the GanttView would take so long to bind data or allocate something? I have also seen this behaviour with the UltraWinGrid, so it might be a common issue.

As said, I'll try to produce a little sample; hope it doesn't take too long...

This indicates a couple possible factors which may be causing hang up for your application:

1. The data itself may be contributing to the lag.  If there were any way for you to use data more similar to that of your production application you may see the problem reproduced.
2. The data retrieval layer could be contributing to the lag.

If the former is true, it is possible that the control has a weakness servign that particular data, and the reproducing sample would be greatly appreciated so that we could investigate why the control is weak for it.  If the latter is true, the issue may exist somewhere outside the GantView.

Please let me know if you uncover any other pertinent information.

Still can not reproduce the issue outside the project.

Nonetheless, I found that the InitializeTaskGridRow-event takes most of the time. I have 6 custom columns, which are filled with values from the datasource. Value assignment (e.Task.SetCustomProperty()) is utterly slow, between 4 and 16ms per row.

Might it be a problem that these values are bound values? In the sample, custom values are unbound.

Your last point is valid. It would be worthwhile to try saving a portion of your application data (or data with the same structure) to a static data source, and then binding your ganttview to this data source and seeing if the binding factor decreases the performance of the control.

In your origional application, is the data loaded into an object in memory and then bound to the control?  If you are using the control to access the data directly from your database, this data retrieval process could potentially be a key factor affecting the performance.

Regarding the SetCustomProperty(), you may try providing a static value. This would test if the performance issue lies in the SetCustomProperty() itself, or somewhere in the logic providing a return for SetCustomProperty().

At any rate, if you could attach your sample so far, I would be happy to take a look at it and perform testing on its performance. If you could make the sample data resemble the data structure you are using in your application, that may provide me more insight regarding the underlying issue.

I did

a) fill custom columns from a static data source
b) fill custom columns from a detached data source

Both of which did not improve things.

My application data is stored into a DataSet in the presenter after retrieving it from the database, before being bound to the view.

I also recognised that the ultraGanttView_InitializeTaskGridRow event ist called twice for each row each time, which would already make up for 50% of the wasted time.

Also, merging the current data with updated data from the database (DataTable.Merge()) is too slow, i found that this is caused by the destination table having modifications. When I call AcceptChanges() on that table upfront, the custom columns are not created and ultraGanttView_InitializeTaskGridRow always fails with NullReferenceExceptions.

I will provide a sample asap, but have other tasks, too, atm :/

OK, I will continue to search for a cause from our end while you work on the sample.

Thanks Mike,

as an additional information, we are using v14.2 of the Infragistics DLLs (probably obvious from the sample). Unfortunately, upgrading is not an option.

I will not be around the office for the upcoming 4 weeks, but of course am eager to hear any results. Can I track the issue (Development ID) somehow, similar to tracking replies to this thread? Maybe with our company's account that is linked to the Infragistics licences?

Greetings,
WeirdAl

I have reproduced this issue and I have asked our engineering staff to examine it further. To ensure that it will receive attention, I have logged this behavior in our internal tracking system with a Development ID of 219564. The next step will be for a developer to review my investigation and confirm my findings, or to offer a fix or other resolution.

Please let me know if you need more information.

Hello,

Thanks for sending your sample. I can see that the calls to e.Task.SetCustomProperty in the InitializeTaskGridRow handler are having a large impact on the performance. I will review this further and keep you updated with my findings.

Please let me know if you have any questions.

Still no sample, but here is what I found out lately:

It is not the data binding itself which is causing the problems, it's solely the fault of InitializeTaskGridRow. After I removed a call to Refresh() immediately after the data bindings are created, the InitializeTaskGridRow is now executed a bit later.

Nonetheless, there are a couple of questions about InitializeTaskGridRow that popped up:
1. Why is InitializeTaskGridRow always called twice for each row? The call stack is the same in both calls, first call takes about twice as long as second call. When called second time for same row, custom values are already set before SetCustomProperty() is called, so that second call is totally useless.

2. The more custom properties, the longer the Init takes (obviously). Currently, I have 6 custom properties; Initialization of each row takes between 2ms and 16ms, at a total of roughly 3.350 rows (each called twice as stated above!). Is the lack of performance with (a number of) custom properties a known issue? I managed to find another forum post about that, but it lead to nowhere...

3. As already stated in my previous post, I am also having issues with my DataSet.Merge() on updating, because I am having pending changes in the merge destination table. It is adviced to call AcceptChanges() before Merge() to speed things up. Problem is, when I call AcceptChanges() on the DataSet (the one that is bound to the GanttView), all of the task's custom properties will not be created and InitializeTaskGridRow will throw a NullRef-Exception. How is AcceptChanges() affecting creation of the custom properties...?

Many thanks for all your efforts!

€: I put together a sample now which almost behaves like my project, exfept InitializeTaskGridRow is only called once instead of twice.

As you will notice, performance is ok for up to 1000 total rows, beyond that it gets worse rapidly! InitializeTaskGridRow takes exponentially longer for each row the more total rows there are...