Performance problems

Hi Magnus,

That's odd, I'm not really sure what the difference would be, if everything is loaded in the same conditions (assemblies containing the objects already loaded, etc.).

Note that there is an “Optional Optimizations” topic in the documentation for the product that describes several optional ways to improve the performance even more.  You may want to check that out and see if any of those things help, if you haven't already.

I presume nothing came of this. We are using the very latest version and are experiencing the same issues. Approximately 1-1.5 second or so delays when changing the selected item object. 

This wouldn't be so bad if it didn't freeze our entire UI during that time. We are writing real-time data to various windows via DirectX and everytime we change the property grid's selected object the entire application freezes.

We have implemented the optimisations listed in the help file but they do not make any difference.

We've also tried spinning off the work to a background thread but due to the work needing to be done on the UI thread for the PropertyGrid it makes no difference.

Using ANTS Profiler and JetBrains dotTrace confirm these PropertyGrid UI freezes too. Unfortunately we don't have the source code to see what is really causing the delay under the hood.

Hi Gareth,

When we perf profile selected object updates, the vast majority of the time is in WPF measure/arrange logic, which unfortunately does need to be done on the UI thread.  We would like to look into seeing if we can come up with a simpler way of implementing that control that does away with some of the bloat of the WPF controls that are currently used and gets more low-level.  It's on the TODO list but we haven't started on that work yet.

Yes, that is what our profiling result show too (that the majority of time spent is in the WPF measure/arrange logic).

Do you have any timescales for this? We are pushed to get our product complete by mid-summer 2015 and the performance impact we are experiencing across the entire system when we use the property grid may mean we have to look at an alternative way to do it.

Hi Gareth,

Unfortunately we have projects that are active or planned likely through the end of summer.  After those, we will prioritize what to work on next.  Rewriting the core PropertyGrid internals is an item for consideration at that time but I can't say right now if it will definitely happen then.

I also think that the performance of the PropertyGrid is problematic and is the weakest point of this overall nice product.

Enabling virtualization and making sure that the visible grid is not too tall improves it. However I've encountered several bugs that seem to be related to TreeView virtualization. Including a very bad issue that completely freezes the process.
Due to this issue I'm only enabling virtualization on .Net Framework 4.5.2+.

We have also encountered performance problems with WPF involving code that has to be executed on the UI thread, but actually WPF is not limited to just one UI thread. So I believe the solution would be to create a second WPF UI thread because that should greatly alleviate these kinds of problems, and nearly everyone these days has a machine with four cores that facilitate concurrent multiprocessing. This kind of functionality is not easy to implement because multiple UI threads with WPF are complicated to work with, but that is one of the reasons people purchase these software toolkits to provide functionality that they cannot easily implement themselves. Ideally the really difficult code would be hidden somewhere in the Actipro Dlls so that developers don't have to fight with it.