DevExpress XAF is a framework for .NET and Visual Studio developers who wants to create Office-like LOB apps for desktop, web and mobile faster and without hiring a large team.
Friday, March 24, 2017
Faster opening of DetailView with many visible ListPropertyEditors (not in tabs) in complex XAF solutions with lots of Controllers - YOUR FEEDBACK IS NEEDED!
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.
As always, we will be more than happy to hear from you after real tests with your apps.
Subscribe to:
Post Comments (Atom)
Thank you Guys for your help!!
ReplyDeleteWell I'm having this problem(slowness in a webapp with hundreds of controllers) with one of my customers but we are in 16.1. do you think there is something we can do to fix it without upgrading?
ReplyDeleteI am very glad that you are dealing with acceleration-based applications XAF (speed-up start app, …). This solution looks good. We have greater application (about 1000 classes). We constantly fighting with speed of the opening ListView and DetailView. We solves it for some critical view with this construction: svp.CreateAllControllers = false; and manual creation controllers. But this solution is very laborious for us.
ReplyDelete@Jose:
ReplyDeleteI am afraid it is difficult to migrate these changes to v16.1 + I cannot 100% tell you whether it will ever help in your particular case, because each performance issue is different and it is first required to perform careful profiling to identify its source. If this issue is important for your v16.1 client, I suggest you contact us using the https://www.devexpress.com/ask service and provide additional details on your case so that we can assist you further.
@Stepan: Thanks for your feedback. I must emphasize, however, that this particular optimization is about Controllers, not classes in the first place. We will be more than interested to learn more about your current optimization solution in the Support Center (https://www.devexpress.com/ask) and can probably provide recommendations after we see it in action. Thanks.
ReplyDelete>>We constantly fighting with speed of the opening ListView and DetailView.<<
BTW, have you profiled your particular app execution? If so, what are the top-heavy routines in the case of ListView and DetailView?