What is behind this optimization?
With XAF v17.1, we have introduced some optimizations with regard to Controller creation for a Frame inside ListPropertyEditor, which is usually used to represent associated detail collections. That main idea behind this optimization is filtering out certain Controllers by their TargetXXX properties and not creating them at all .On our test machines, which are often multi-core i7 monsters with 16GB ROM, the loading time after this optimization was cut on 0.2-0.3 seconds or on 20% depending on the view configuration (we expect double time on your real client machines with budget i3-i5 or lower CPUs).
Specially for early testing 1-2 months prior to the official release, we have introduced a feature toggle in the current XAF v16.2 and showing this feature there as a preview.
When should I be interested in this?
You can skip this post if you do not have many custom Controllers in your apps, because the effect of our optimization will unlikely be noticeable in your case.
You must definitely read further if you have hundreds of own Controllers + use third-party modules like Xafari/eXpand with many custom Controllers in them.
Another condition is DetailView layout configuration, which I would rather clarify with a couple screenshots:
If you have the A configuration, you will NOT benefit much from the optimization we introduced, because there is only one visible ListPropertyEditor in the active tab that affect the overall parent DetailView opening.
If you have the B configuration, you have several visible ListPropertyEditors that require creating Controllers for their nested Frames immediately with the opening of the parent DetailView and thus slow things down a little. You can either turn our optimization on or consider hiding these ListPropertyEditors behind the tabbed group.
How do I test this right now?
Please download the latest DevExpressComponents-16.2.5.17082.exe build and set the new XafApplication.OptimizedControllersCreation property to True in the constructor of your XafApplication descendant located in the YourSolutionName.Wxx/WxxApplication.xx file (or in the YourSolutionName.Win/Program.xx or YourSolutionName.Web/Global.asax.xx files), e.g. as follows:
namespace MainDemo.Win {
public partial class MainDemoWinApplication : WinApplication {
public MainDemoWinApplication() {
InitializeComponent();
this.OptimizedControllersCreation = true;
}
Typical 'preview' caution & other important things to consider
1. Since this is a preview in v16.2, we would not recommend you use this in production right away. As of now, there may be issues in XAF code and even in code of third-party modules, which were not yet adopted and tested in accordance with our optimization.
2. The Frame.GetController<T>() calls may start to return null, because Controllers in the ListPropertyEditor's Frames are now filtered by TargetXXX properties. So you may need to modify your own code to add null-checks (same is true for third-party module code).
3. Let me know if you happened (I hope NOT!) to override the CreateControllersCore or CreateControllers methods of your XafApplication so that I can provide additional guidelines so that everything continued to operate properly in your case.
What else can I tune up?
1. If you already hide certain ViewItems behind layout tabs, make sure you have the XafApplication > DelayedViewItemsInitialization option set to True. This is already the case for new XAF solutions for many years, but you might customize this in your particular project globally or per specific DetailView only using the CompositeView.DelayedItemsInitialization property.
2. In WinForms apps, you can consider setting the WinApplication.IsDelayedDetailViewDataLoadingEnabled property to True (for non-Tabbed MDI only!). When it is enabled, the Detail View with empty editors is immediately opened, and then data is asynchronously loaded and displayed, which improves form responsiveness and overall user perception.
3. If your forms do not open quickly, the first step is always to measure your code performance using specialized profiling tools to see exactly what can be optimized and how. This a general programming task which we developers need to work on sometimes regardless of how good the developments tools we use are, because it is possible not to follow best practices or make other kinds of mistakes that lead to writing bad or slow code. To help our users diagnose and solve such problems faster, we have specially collected general and XPO/XAF-specific information on how to avoid such problems at How to measure and improve the application's performance.
Our future considerations
We hope to research the possibility of applying this optimization to LookupPropertyEditor, DetailPropertyEditor, DashboardViewItem and even certain rare cases with standalone Frames. In theory, this can speed up initial view loading even more, but we cannot promise any time frame or results at this stage.