In my Gantt-View, data binding is taking ages.
Initial binding takes more than 30 seconds for a few thousand records, updating is slightly faster at around 8 seconds.
Even more puzzling, after update data has been merged (DataSet merge), I try to restore the last active task. When I allocate the task to the GanttView's ActiveTask property, again it takes longer than 30 seconds.
// re-select formerly selected task if (_lastActiveTask != null) { foundTask = FindTask(_calendarInfo.Tasks, _lastActiveTask); if (foundTask != null) ultraGanttView.ActiveTask = foundTask; <--- this takes ages }
When I remove this allocation, the system will hang at the next allocation to the gantt chart:
// re-set scrollbar position if (_firstVisibleTask != null) { foundTask = FindTask(_calendarInfo.Tasks, _firstVisibleTask); if (foundTask != null) ultraGanttView.EnsureTaskInView(foundTask, true); <--- this takes ages, when code above is removed }
To sum up, always the first allocation plus binding and updating is taking far too long. I assume I missed out on some weird setting and appreciate any help :)
Before doing all that stuff, of course I do this:
ultraGanttView.BeginUpdate(); ultraGanttView.SuspendLayout();
Hello,
I don't see anything out of the ordinary within the code snippets you posted. In order to help me investigate this issue, could you post a small sample project which reproduces the issue? If I could reproduce this issue the way you are seeing it, it would greatly help me and our other developers to investigate what may be causing this issue.
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...
I've made the private support case associated with this issue available for you to view. You should be able to see the status of the development issue on your support activity page.
Any current fix will be applied to versions 15.2 and 16.1. It will be necessary to upgrade in order to benefit from any fix we apply.
I understand that it is not a trivial matter for you to upgrade. I will work with the team to see if there is any possibility that you can work around this issue in 14.2.
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.
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...