Layout.Win - Low performance when opening a Detail View containing a lot of tabs

Hi Frode,
By design, all views are instantiated at once, during the initialization phase. However, data will be loaded only when the view is activated, so in most situations, this shouldn't be a major problem. See a similar scenario, discussed in the Cache Views thread, and try recommendations, provided there. In addition, track the following suggestion regarding further performance improvement: Layout - Improve Performance for Complex DetailViews.
Thanks,
Alex

How do we vote for resolution of such suggestion? Or even pay for progress of that?
For us, implementation of S132374 is crucial, and you are just contemplating?
-frode

"However, data will be loaded only when the view is activated, so in most situations, this shouldn't be a major problem."
Can you please reread Layout - Improve Performance for Complex DetailViews yourself, where you confirms that the problem is loading of all the view layouts.
To conclude - it _is_ a major problem.
-frode

Hello Frode,
>>
Can you please reread Layout - Improve Performance for Complex DetailViews yourself, where you confirms that the problem is loading of all the view layouts.
To conclude - it _is_ a major problem.
<<
I am afraid you have interpreted the information, given in the suggestion, incorrectly. I should apologize for the inconvenience if it was caused by my answer. Anyway, I will update the suggestion's description with further details soon.
>>
Why is it that detail/listviews in non active tabbed groups are created when the (master)view is opened? Our AQtime profiling show that XafApplication::CreateListView and XafApplication::CreateDetailView are called as many times as there are views in the hierarchy, not as many times as there are visible views.
<<
Yes, you are right, the List View object is created when the master View is opened for each tab, but this should not cause performance problems, because controls for the View within the tab are created, and data is bound only when the tab is activated. You can ensure this even without using a special tool. Just add a simple ViewController to the MainDemo application, and handle the View.ControlsCreated event. Then, set a breakpoint in the event handler, and open the Detail View for a Contact record. Also, run the SQL profiler and see that queries are sent to the database only when a tab is activated.
>>Our AQtime profiling show that XafApplication::CreateListView and XafApplication::CreateDetailView are called as many times as there are views in the hierarchy, not as many times as there are visible views.
Please check how expensive this call is in your application. In general, it should not affect performance at all. Anyway, we would like to ask you to provide your own results here.
Regarding the S132374 suggestion, when working on it I reported the S33424 issue that has already been fixed. This fix should decrease the time, spent on opening a complex DetailView up to 1 second.
>>To conclude - it _is_ a major problem.
If you have major performance problems when opening a Detail View, it doesn't necessarily mean that it's caused by the fact that all the ListViews are created at once.
I believe that only a detailed research, based on profiling, including profiling of queries, sent to the database server, can prove that there are problems in the underlying framework or its components. From my experience, when dealing with similar customer problems, about 95% of all the cases were closed by finding mistakes in customer code (incorrect design of business objects, controllers, PropertyEditors, etc.).
Take special note that I do not blindly defend us here - I admit that we may have performance problems in our products. And we would appreciate your help in improving our products if you could provide us with essential details that prove that there are real problems with DX stuff.
In this case, please create a separate private issue in our Support Center and supply your entire application and profiling results. We will greatly appreciate this.
Thanks,
Dennis

I have attached a stripped down version of our application that includes two views you can switch between to profile the time XAF needs to build up such complex views. There are no custom viewcontrollers, only business objects with enough logic to get it running in this example.
On my computer (Intel Q9400 @ 2.66GHz, 1.97GHz 2.50 GB RAM) this switching takes ~4 sec, before we redesigned (removed some tabs) it took 6 sec. Viewcontrollers and data add more time.
As I see this the only solution is to redesign XAF so XafApplication::CreateListView and XafApplication::CreateDetailView only are called for visible views as suggested in S132374.
(Using an empty sql db called SticosRM, just give a username (Brukernavn) and a blank password in login dialog)

Hello Frode,
Thanks for the sample. We are researching it and will let you know our results ASAP. Please bear with us.
Thanks,
Dennis

Hello Frode,
Thanks for your patience. We are afraid that we faced a great difficulty when working with the solution you provided. It was created in a locale which does not use English and so we run into hundreds of complication errors and missing source files.
We could force Visual Studio to recognize missing files by excluding them and including them again into the project, but we cannot resolve the problems with Unicode classes and members. We tried to follow the recommendations given by MS at http://msdn.microsoft.com/en-us/library/w11571b4(VS.80).aspx but failed because opening and saving files in Unicode encoding doesn't really help. This day we tried everything, but still cannot get your solution to compile without errors. Could you please provide us with a solution that can be opened in a regular dev environment with English culture? Or, provide us with exact instructions on how to convert the solution you provided? Another way I see is to provide, not the entire solution, but some parts of it that are needed to demonstrate the issue with slow tabs.
Thanks,
Dennis

This project was created with VS 2008 (not 2005, as your MS link points to), on XP Professional. Both in none localized versions. The files are in UTF-8.
So I really don't understand your problem, unless you during unzipping has converted the encodings.
Could you please give a sample of one error message to clarify what the problem is?

I found the problem, not all files where in UTF-8 format, some where in WIN 1252 (Western Europe), I shall fix that and post a new zipfile.
-frode

Hello Frode,
Thanks for the update. We are awaiting for your updated solution.
Thanks,
Dennis

The enclosed zip should contain only UTF-8 encoded files. If you need more specific information about something I can be reached at frode at sticos dot no.
-frode

Hello Frode,
Thanks for the update. We are working on your project, and will keep you informed on our progress. Thanks for your help.
Thanks,
Dennis

Hello Frode,
We still cannot build your project, even after your last modifications. Attached is a screenshot that shows the same problem as we had before. We tried to run it on both on our work machines, as well as on virtual ones. The results are still the same - your solution is not compilable due to errors caused by some source files and some class names that are unrecognized by Visual Studio. We see two ways to progress with this problem:

1. Let us know what we are doing wrong, if this is the case here, and provide us with the steps to build your solution in a regular dev environment with an English location;
2. You correct (rename) these problem source files and classes by replacing unrecognized characters, and ensure that your solution can be built in a regular dev environment with English location;
3. You prepare a small (http://community.devexpress.com/blogs/ctodx/archive/2009/01/08/a-request-for-simple-example-programs.aspx) demo that demonstrates the same problem as your whole solution, and send it to us. We will be glad to research it and let you comment on the performance problem you found.
   We look forward to hearing from you.
   Thanks,
   Dennis

Hi Dennis
Well, here is a new take. I zipped the files into an utf-8 archive (enclosed).
You will need a tool like http://dotnetzip.codeplex.com/ to unzip these, as Windows Compress Folders doesn't understand that format.
You should with this be able to unpack the files to their original names, and have filenames as named in the VS project file.
If there still are problems, please use VS 2008 and give a error dump from the VS build process.
As for your suggestions:

1. Let us know what we are doing wrong, if this is the case here, and provide us with the steps to build your solution in a regular dev environment with an English location;
   The problem as described in your screenshot is that VS can't find files with non-US characters in their names. The cause for that is probably the winzip format that encodes filenames in local character encoding instead of utf-8. A problem this new included zipfile should solve.
2. You correct (rename) these problem source files and classes by replacing unrecognized characters, and ensure that your solution can be built in a regular dev environment with English location;
   I am a bit amused by the fact that your are not able to search for bugs in a "foreign" environment, when your product is aimed for such. As for problems with classes, I didn't see any descriptions of such in your last reply.
3. You prepare a small (http://community.devexpress.com/blogs/ctodx/archive/2009/01/08/a-request-for-simple-example-programs.aspx) demo that demonstrates the same problem as your whole solution, and send it to us.
   Well this is, by the nature of the issue, not an alternative.
   Hope my last effort is enough to push this further because the lack of speed in our application is starting to become a show stopper.
   -frode

Hello Frode,
Thanks for the update. I could finally compile your solution, but still there were problems with the Definerteør.cs file, because it was not recognized by Visual Studio when I opened your solution. I had to exclude it and then include it in the solution to solve this problem.
After that, I could build your project without any problem. But then I could not run it because I had neither test database nor login details. Above you suggested using the Brukernavn user name with an empty password and an empty database, but for some reason, it did not work for me.
I had to debug your solution and go through the exceptions to additionally modify the DivUtilities class to make it possible create a new database. Then I found that a new user (Ansatt) was created (SticosRM.Module.Win) based on the info specified on the login form.
And I was able to log in to your application with a Test user and an empty password.
Figuring out all these things cost us inadmissible amount of time that we, for example, could have spent on implementing features in the product, other customers or real researching of the exact problem you experienced.
We appreciate your help, that you could finally send us an almost compilable solution to demonstrate your problem, but in the future, we would also appreciate your effort in providing exact instructions on how to run it in a regular dev environment.
Otherwise, based on the http://community.devexpress.com/blogs/ctodx/archive/2009/01/08/a-request-for-simple-example-programs.aspx blog post, we will always request simple programs and instructions to replicate your problems.
Finally, I would like to say that we never abandon from researching large customer projects with demo or real databases that can be easily run (perhaps, with the help of provided exact instructions) in a regular dev environment and easily researched by us.
After running your project and testing the scenarios of switching between navigation items, creating a new object and closing the DetailView we see some performance problems in your application.
This is still true even after updating to the latest version of the suite and using the following option we recently introduced:

C#
static void Main()  
{  
    DevExpress.ExpressApp.Editors.DetailPropertyEditor.UseLazyViewInitialization = true;  

We are now profiling your application to exactly see why your ListView in the MasterDetailMode demonstrates low performance. Please bear with us.
Thanks,
Dennis
P.S.
I suggest you update your application to the latest version of the suite 9.3.3 because it contains a lot of improvements including ones with regard to performance. For example, your application works much faster for me in this version (please run it in the Release configuration).
If all goes according to plan, the version 9.3.3 will be out in a couple of days.

Version 9.3.3 shaved of aprox. 15% of execution time.
DevExpress.ExpressApp.Editors.DetailPropertyEditor.UseLazyViewInitialization = true; didn't seem to have any effect (or degrading performance with some small percentage)

Hello Frode,
Thanks for the feedback on the version 9.3.3. We are happy to hear that it works better for you.
The UseLazyViewInitialization option works only for embedded DetailViews. It doesn't affect nested ListViews. So, if you have a root DetailView that has a lot of tabs where DetailPropertyEditors are placed, then you should experience a better performance than when not using it at all.
However, in your concrete situation, you have a lot of nested ListViews on tabs, and so this option may not have a noticeable effect due to the factors mentioned above.
Concerning your issue, we are still working on it, and will let you know our results ASAP. Thanks for your patience.
Thanks,
Dennis

Hi,
There are also a few related suggestions on the XtraLayoutControl (Windows Forms) I think is worth letting you know about:
    Performance - Improve resizing performance
    Performance - Improve the "Ungroup Tabbed Group" operation performance
    Performance.Scrolling - Make the LayoutControl to be a descendant of the XtraScrollableControl class to improve scrolling performance
Concerning Web layout, we have a separate suggestion in this regard: Layout.Web - Provide the capability to load tabbed groups content dynamically. I suggest you track it as well.
See Also:
Layout - Improve Performance for Complex DetailViews
Thanks,
Dennis

Hello,
We have found that to improve performance of a complex View, it's possible to remove unnecessary items, corresponding to object properties that are not displayed in the main View, but still present in the Customization form.
The below model customization demonstrates how it can be done:

Code
<Application>  
    <Views>  
        <ListView Id="MyDomainObject_ListView">  
             <Columns>  
                 <ColumnInfo Id="MyProperty"  />  
                 ...  
             </Columns>  
        </ListView>  
        <DetailView Id="MyDomainObject_DetailView">  
            <Items>  
                <PropertyEditor Id="MyProperty" Removed="True" />  
                ...  
            </Items>  
        </DetailView>  
    <Views>  
</Application>  

It will help you save up to 1 second on opening a complex View.
However, we're still working on this issue and will keep you updated.
Thanks,
Dennis

You lost me in this last comment, could you please elaborate?
Is there several ways to remove a field/property from a view?
We never show fields that are not meant for viewing, as I don't think anyone would, so what is this suggestion really suggesting?
Sincerely,
Frode

Hello,
Thanks for the feedback.
>>We never show fields that are not meant for viewing, as I don't think anyone would, so what is this suggestion really suggesting?
I meant that there are cases when Views contain invisible fields in the Customization form (belonging either to the Layout or Grid controls). You can improve the startup performance of such Views if you remove these invisible forms from the Customization form (e.g. see a screenshot of the layout's customization form).
>>Is there several ways to remove a field/property from a view?
Yes, you can do this either through the application model customization or at runtime, using the control's customization facilities.
Let me know in case of any further difficulties.
Thanks,
Dennis