Considering WPF datagrid Control changes

Jul 3, 2013 at 4:34 PM
So, after implementing the filter feature, I issued some performances problems.

These issues are not due to my code but to the system that use so much time re-rendering the cells.

So Francois and I been thinking about a solution for these issues, and we converge to a solution that is the following one :

The WPF element datagrid is not the ideal one for our purpose, since the datagrid is normally used for rows data modification. I think I have to dig deeper to find the ideal control that will be able to rebuild the gridview fast enough for our purpose.

I think we really need to discuss about this before making any changes.
Coordinator
Jul 3, 2013 at 7:17 PM
I have not seen the filter, yet, but you are probably talking about the column filter for the marker column. I have seen that type of problem with other column filters too.

I could be wrong but I think its due to the fact that the filtering is not done in an async thread, but in the UI thread. Maybe you find a better control but I would rather try and research a better way of filtering the gridview. Even posting a question at Microsoft's WPF Forum might be worth a try.

I don't think there is another control that scales out better than one we have - but we can of course try and find one.

My guess: Most likely we have to handle thinks differently in the ViewModel part - such that the UI thread is not blocked.
Jul 3, 2013 at 7:41 PM
The data grid control is a heavy control designed with edition capabilities and so much more.
It is well known for slow performances.
In the data grid there were 5000 entries only, and even the scrolling was lagging...

No wonder why there are many different implementation of data grid on the web.

We have analyzed performances and the time is really consumed by wpf and not by the filtering system.
Of course it exists some tricks, but my gut feelings tell me it won't scale up as we need.

Personally I would like to try 2 controls:
1) the data grid from extended wpf toolkit that can handle hundred of thousands of items (at least they say)
2) use the wpf grid view which main feature is speed

F.
Coordinator
Jul 4, 2013 at 7:42 AM
OK, I see. I guess I am wrong then :-) sorry, but its really hard to follow you - I do not mind replacing the control since we do not use it for editing anyway.

Could you send me sample data with a more specific description (branch, build, steps to reproduce the problem) so I can get back on board with you?
I would be interested to learn how you analyzed it.

I guess this will be a good test for WPF since a sales claim is that you can use multiple view controls on one viewmodel :)

Thanks D
Jul 4, 2013 at 8:10 AM
Edited Jul 4, 2013 at 8:39 AM
I think you misunderstood when I talked about filters, I was actually speaking about the query filtering I've just implemented. But it's also true for the column filtering tho. The main idea is to speed up the rendering process of the log rows

I've just pushed the last commit.

I'll join a log data file. here

Just run the app, load the file and then go into the filter tab (bottom right) and type for example : "method equals method3"

Then click on the validation button. It will take about ten seconds or more for WPF to redraw the grid.

We used ANTS performance profiler to analyze how much times it take for each method to be execute.

Let me know if you suffer any troubles
Coordinator
Jul 4, 2013 at 4:58 PM
Edited Jul 4, 2013 at 5:07 PM
Thanks I have the log4net file but I cannot build the application since there are missing Irony assemblies:
  • Irony
  • Irony.Interpreter
Do I have to set this up on my computer as a pre-requisite or did you forget to commit it?

But I can verify this problem with the last released version using the normal column filter it is quit annoying to wait until it scrolls you are right. Strange we did not see this earlier... thanks though
Jul 5, 2013 at 8:58 AM
Edited Jul 5, 2013 at 9:35 AM
Sorry, GIT automatically ignored them when I commited the changes.

I've added them.

I think we should try to implement the GridView component since it's a Windows Form that fit exactly with our purpose and we won't need to add another reference using the extended wpf toolkit.
Jul 9, 2013 at 8:44 AM
Edited Jul 10, 2013 at 11:01 AM
Well, the gridView component doesn't solve this problem and doesn't allow us to hide the columns (no IsVisible property)
I've been discussing with some c# programmers and apparently the solution is : "Deal with it, try to reduce the number of columns or the number of rows before rendering"

So, i'm thinking about getting back on the standard datagrid and make the filtering as an async func allowing the user to cancel it.
Jul 10, 2013 at 11:03 AM
Edited Jul 10, 2013 at 11:04 AM
Ok, so the problem is (I think) solved.

I kept the DataGrid component, but instead of changing the visibility of my entries (since Windows was re-redering every entry then, this was the time consumming task) I used the property Filter of the CollectionView (which is binded to the datagrid component in WPF and is based on the ObservableCollection of logentries)

So the filtering is taking something like 2sec MAX I think it is pretty much ok.