Current filter:
                                You should refresh the page.
                                  • This article describes how to determine the cause of most common performance issues and solve them.

                                    Performance profiling tools
                                    The best way to determine the underlying cause of a performance problem is to profile your application using a specialized performance profiler tool or enable logging. For more convenience, see the tools below grouped by the most popular profiling tasks when developing an XAF application.
                                    Database or SQL queries performance:
                                        SQL Server Profiler and similar tools for each db engine*
                                        Log Files (turn on the XPO switch in the *.config file)
                                        XPO Profiler (advanced scenarios only)
                                    See also the Database maintenance recommendations for applications created or used with XPO or XAF article.
                                    .NET or native code performance:
                                        Profile application performance in Visual Studio
                                        SmartBear AQTime, RedGate ANTS Performance Profiler, JetBrains dotTrace*
                                    Web client side JavaScript/HTML performance:
                                        Developer Tools of your favorite web browser (Internet ExplorerGoogle Chrome)
                                    Memory consumption and leaks:
                                         Profile Memory Usage in Visual Studio
                                    Troubleshooting Exceptions: System.OutOfMemoryException
                                         Memory leak via event handlers (MSDN)
                                         Windows Performance Monitor (Perfmon counters to check memory leak)
                                         SciTech Software .NET Memory Profiler (About profiling memory leaks), SmartBear AQTime, RedGate  ANTS Memory Profiler, JetBrains dotMemory*
                                    * The list of commercial profiling tools above is incomplete and is provided for information purposes only. DevExpress is not responsible for nor does it endorse any content, information of services offered by third-parties.

                                    Be sure to check out the basic concepts in public community resources, e.g. Microsoft documentation at Profiling in Visual Studio  and similar StackOverFlow questions before getting started. When profiling performance, it is  also important to consider whether a feature is used for the first time or subsequently as it may give you quite different results, especially when third-party libraries are used. You may find the The Compromise Between Development Time and Performance in Data-Driven ASP.NET MVC blog post helpful as it describes how to use the aforementioned tools and techniques together. If you do not want to research this on your own or cannot allocate your own resources at this time, we can certainly recommend third-party consultants who have expertise with XAF and performance profiling (e.g., from

                                    In addition, check this list of the most frequent causes of performance issues and make sure that you are following all the advice from this list in your application.
                                    1. General issues:
                                    1.1 The application or a certain View is loaded slowly for the first time, but subsequent loads are performed significantly faster.
                                    Solution: The majority of this time is likely required to load additional assemblies or compile MSIL code. When the issue occurs in a certain View, this View likely uses a control that is not used by other Views, e.g., SchedulerControl, XtraReport. To improve performance in this case, use NGEN. Refer to the Why does my code take longer to execute the first time it's run? article for additional information.

                                    1.2 A View is painted slowly, and the application freezes when it is necessary to redraw this View.
                                    Solution: Check whether any exceptions are thrown when the View is displayed. Even if these exceptions are handled and do not break the application's execution, a lot of exceptions may cause noticeable freezes, especially during debugging. An example of such a situation is when there is a mistake in the column's display format definition. In this case, a FormatException will be thrown for each cell. To see these exceptions, enable Common Language Runtime Exceptions and disable the Just My Code option in Visual Studio. See How to: Break When an Exception is Thrown for more details.

                                    1.3  The application creates a lot of entries in the Output window during debugging, and this slows down its performance.
                                    Solution: Lower the detail level of the eXpressAppFramework and XPO diagnostic switches in the configuration file. See the Log Files topic for details.

                                    1.4 A Web application works very slowly in general.
                                    Solution: Ensure that the Browser Link feature is disabled in Visual Studio. Refer to the Visual Studio 2013, 2015 - Troubleshooting issues related to Browser Link feature article for additional information.

                                    1.5 The ListVIew is loaded slowly when the database table contains a lot of records (e.g., more than 100,000).
                                    Solution 1: If you do not need to show all these records in a single View, apply a server-side filter to your ListView - see Filter List Views.
                                    Solution 2: Enable partial data loading - Server Mode - to load records dynamically when the ListView’s control requests them. To do this, open the Model Editor, find the ListView model in the Views node and set its DataAccessMode to Server. For Pivot Grid List Editors, refer to the Ways to improve Pivot Grid List Editor or PivotChart performance with large amounts of data solution.

                                    1.6  If the security system is enabled, make sure the application uses the most recommended settings as per the Security - How to reduce the number of permission requests and improve overall performance KB article.

                                    1.7 Determine the time spent in the network when your Web browser requests or SQL queries are executed (back and forth). You can learn more about this from public community resources on the Web:
                                    Network itself can often be an issue when remote databases or services are used (e.g., a database hosted in a cloud-based infrastructure like Azure or when the database is located far away from the server). This is often noticed when comparing application performance in production vs development environments. So in such cases, it is recommended that you analyze differences between the production and development environments and probably experiment by making changes one by one.

                                    1.8.  Excessive Conditional Appearance rule updates due to control value changes. Refer to the How to avoid excessive ConditionalAppearance rule updates and improve overall form performance article for a solution.

                                    2. Issues caused by your persistent class design and business logic
                                    First, make sure that you follow XPO Best Practices.
                                    If they do not help or your code is already fine, check what queries are performed while loading data from the database. Here are ways to do this:
                                     - Using SQL profiling tools available for your database engine. For instance, there is a SQL Server Profiler tool for Microsoft SQL Server.

                                    NOTE:  If you are using XPO for data access in an XAF application, the simplest way to view SQL queries without any third-party tools is to open the application's configuration file (e.g., app.config) and uncomment the XPO diagnostics switch in it:

                                    <system.diagnostics> <switches> <!-- Use the one of predefined values: 0-Off, 1-Errors, 2-Warnings, 3-Info, 4-Verbose. The default value is 3. --> <add name="eXpressAppFramework" value="3" /> <add name="XPO" value="3" /> </switches> </system.diagnostics>

                                    As a result, SQL queries will be displayed in the Output window of Visual Studio and written to the eXpressAppFramework.log file (see Log Files).
                                    A more complex solution is to use the XPO Profiler tool or approaches described in the How to log the SQL queries made by XPO article.

                                    After configuring one of these approaches, load the problematic ListView and check the logged queries. If their summary execution time takes the majority of the ListView's loading time, query optimization is required. Here are the most frequent cases:

                                    2.1 Server-side filtering, sorting or grouping is performed slowly because the database table does not contain the necessary indices.
                                    Solution:  Check what columns are involved in the WHERE, ORDER BY and GROUP BY operations and add indices for them. To add an index using XPO, use the Indexed attribute.

                                    2.2 The main SELECT query takes a long time to execute, although the result does not contain a lot of objects. This may occur if each persistent object selected by this query includes a lot of data, i.e., contains images, long texts, references to large persistent objects, etc.
                                    Solution1:  Set the ListView's DataAccessMode to DataView to load only properties displayed in this ListView (be default, all properties are loaded). In reports, use ViewDataSource.
                                    Solution2:  Make large properties delayed, as described in the Delayed Loading topic. Note that delayed properties should not be displayed in the ListView, otherwise you will have case 2.5.1 (see below). If you need to display large reference properties in the ListView, use the solution from case 2.4.

                                    2.3 XPO sends additional queries to load associated (referenced) objects. This behavior is normal for XPO - it loads related objects IDs in the main query, and then loads all these objects in the second query by these IDs. Normally this behavior should not cause performance issues. If it does, there are two ways to alter it:
                                    Solution1:  Include referenced objects in the main SELECT query by applying the ExplicitLoading attribute to the corresponding properties.
                                    Solution2:  If related objects are not used in list views, you can use the Delayed Loading for them.

                                    Note that normally, all referenced objects of the same type are loaded through a single additional query for all records. If additional queries are performed for each record, see case 2.4.

                                    2.4 XPO or Entity Framework executes a separate query or several queries for each record.
                                    Solution: See what additional queries are executed and analyze your business class to understand what code causes this. Here are examples of such cases:
                                    2.4.1 Additional queries load a property of the current business class that is not loaded in the main SELECT query.
                                    Solution:  This property is likely delayed, and there is a ListView column that displays it. In this case, either do not use delayed loading for this property, or remove the ListView column (see Change Field Layout and Visibility in a List View). The same issue will occur if the delayed property is accessed in code while loading objects, e.g., in another property's getter, or in the OnLoaded method.
                                    2.4.2 Additional queries select data from other tables for dynamic values' calculation.
                                    Solution 1: Check whether your persistent class executes the code that loads other persistent objects (e.g., creates an XPCollection or uses a Session's methods like Session.FindObject and Session.GetObjectByKey) in property getters or in the OnLoaded method. In this case, either call this method in another place, e.g., in a getter of a property that is not displayed in the ListView, or remove the problematic property from the ListView.
                                    Solution 2: Check whether there are calculated properties implemented through the PersistentAlias attribute that use collection properties or join operands in their expression, e.g., "Orders.Sum(Amount)". It is important to remember that to get values of calculated properties, the getter that calls the EvaluateAlias method is called, and the EvaluateAlias method evaluates the specified expression on the client side. So, if the PersistentAlias expression contains a collection property, this collection will be loaded when calculating the value. The easiest way to resolve this issue is to hide such properties from the ListView. You can also improve the performance of these properties by pre-fetching associated collections using the Session.PreFetch method. In this case, all associated objects will be loaded in a single query. See an example here: How do I prefetch related details data to increase performance for calculated fields. And finally, you can use the Session.Evaluate method instead of the EvaluateAlias method in getters of such properties. The Session.Evaluate method will cause an additional database query that will evaluate the specified expression on the database side and return a single value - the expression's result.
                                    Solution 3: Change the ListView's DataAccessMode to DataView. In reports, use ViewDataSource. In this case, queries that can be executed on the server side (PersistentAlias expressions) will be included to the main SELECT query, and client-side code that loads data will not be taken into account
                                    Solution 4:  Recalculate property values only when related objects are changed - see Store Calculated Property Values in the Database.
                                    Solution 5:  Implement a calculated column in the database and map it to an XPO property using the FetchOnly attribute (available since v18.2).

                                    2.5 The applications periodically perform the same queries that return the same database records.
                                    Solution:  If these records are changed rarely, it makes sense to enable caching at the Data Layer level to prevent the duplicate requests, as described in the How to use XPO caching in XAF topic.

                                    2.6 An XPO-based ASP.NET application creates a separate database connection for each user.
                                    Solution:  Ensure that the code demonstrated in the Initialization of one XPO data layer per one global HttpApplication ticket is added to the Global.asax.cs  file. Starting with the 15.2.4 version, this code is automatically added by the Solution Wizard, but it may be missing in projects created with an earlier version of XAF.

                                    2.7 An XPO-based WinForms application repeatedly creates and closes database connections on performing asynchronous operations in Instant Feedback mode.
                                    Solution:  Ensure that the following code, which registers the XPObjectSpaceProvider or SecuredObjectSpaceProvider with enabled caching and connection pooling in the data store provider, is added to the WinApplication.cs  file. Starting with the 16.2.5 version, this code is automatically added by the Solution Wizard, but it may be missing in projects created with an earlier version of XAF.

                                    winApplication.CreateCustomObjectSpaceProvider += (sender, e) => {  
                                        e.ObjectSpaceProviders.Add(new SecuredObjectSpaceProvider((ISelectDataSecurityProvider)winApplication.Security,  
                                            XPObjectSpaceProvider.GetDataStoreProvider(e.ConnectionString, e.Connection, true), false));  
                                        e.ObjectSpaceProviders.Add(new NonPersistentObjectSpaceProvider(winApplication.TypesInfo, null));  

                                    2.8 By default, aggregated objects are considered to be an integral part of a master object, and thus, they should be validated together with the master object. The entire collection will be loaded in this instance. Validation may take significant time when an object to be saved exposes a large collection of aggregated objects. (PersistenceValidationController). Refer to the Validation performance - PersistenceValidationController and the Aggregated attribute cause selecting child records one by one on saving the master object article for more information and possible solutions.

                                    Note that this list does not cover all possible cases. There are issues related to a specific database provider or caused by specifics of a legacy database,  scenario-specific issues, etc. A general suggestion is to find out how the query or the database table can be modified to improve performance, and then try to modify your persistent objects accordingly.

                                    If your profiling results happen to indicate problems in DevExpress code, please contact our Support Team and attach 1. your profiling tool log files; 2. your debuggable application source code (including database backup and other necessary files to debug it locally); 3. the description of problematic scenarios so we can research this information locally and assist you further. Thanks.

                                    3. Speeding up the application startup
                                    3.1 According to our research, some XAF WinForms applications are started significantly faster when built with the x86 target platform. Also, when deploying apps to client machines, it is recommended to use the Ngen.exe (Native Image Generator) tool to create native images for deployed assemblies that will decrease the startup time.
                                    In addition, in most cases x64 applications are generally slower than x86 ones. You can find a lot of information about this on the Internet, for example: AnyCPU Exes are usually more trouble than they’re worth and Why does my code take longer to execute the first time it's run?.

                                    3.2 You can speed-up collecting types declared within your custom modules (including <AppName>.Module, <AppName>.Module.Win and <AppName>.Module.Web) by overriding the GetDeclaredExportedTypes, GetDeclaredControllerTypes and GetRegularTypes methods in their ModuleBase descendants. By default, these methods use reflection to go through all assembly types and find the declared business objects, DbContext descendants, Controllers, List and Property Editors, etc. If you override them and return lists of predefined types without calling base methods, these methods will be executed significantly faster. When overriding the GetRegularTypes method, however, it is not necessary to register types that are already returned by the overridden GetDeclaredExportedTypes and GetDeclaredControllerTypes methods. Here is an example from the source code of the built-in XAF module:

                                    protected override IEnumerable<Type> GetRegularTypes() { return new Type[]{ typeof(IModelOptionsSchedulerModule), typeof(IModelOptionsScheduler) }; } protected override IEnumerable<Type> GetDeclaredExportedTypes() { return Type.EmptyTypes; } protected override IEnumerable<Type> GetDeclaredControllerTypes() { return new Type[] { typeof(SchedulerDetailViewController), typeof(SchedulerListViewController), typeof(SchedulerRecurrenceInfoController), typeof(SchedulerResourceDeletingController) }; }

                                    3.3 If your application does not use actions declared through the Action attribute, you can set the DevExpress.ExpressApp.SystemModule.ObjectMethodActionsViewController.Enabled static property to false to avoid searching such actions through reflection at the application startup.

                                    3.4 Starting with version 16.1, you can enable the Application Model caching using the XafApplication.EnableModelCache property . When the cache is enabled, the Application Model content is only generated when the application is first launched. It is then cached to a file and this cache is used to reduce the startup time for future app execution.
                                    Starting with version 16.2, you can enable parallel loading of business types and tune the model cache by setting the static DevExpress.ExpressApp.ModelCacheManager.UseMultithreadedLoading and DevExpress.ExpressApp.ModelCacheManager.SkipEmptyNodes properties to True before the XafApplication.Setup method is called in the YourSolutionName.Win/Program.xx file (learn more...).
                                    In version 19.1, we added various performance enhancements and enabled them by default. Refer to the Performance enhancements in XAF v19.1 for all supported platforms article for details.

                                    3.5 If you are using XPO for data access and have been developing/upgrading your app for a long time, you may end up with dead records referring to non-existent assemblies or types in the AssemblyName and TypeName columns of the service XPObjectType table. Since XPO is always trying to load an assembly by this information during the XPDictionary initialization, it may result in startup performance degradation. To detect this fact, check out your eXpressAppFramework.log file for the "Resolve the 'DevExpress.ExpressApp.Workflow.v11.1' assembly" and similar messages referring to outdated DevExpress assemblies or simply view the XPObjectType records using your database engine tools.
                                    To avoid searching for not used types, you can simply delete or purge unwanted XPObjectType records. Note that some invalid records might be tied with corresponding persistent object records if inheritance mapping is used, and deleting them will lead to foreign key constraint violation.
                                    You can also update these rows manually or by using the ModuleUpdater.UpdateXPObjectType() method as shown in the article: How to: Handle Renamings and Deletions of Business Classes and their Properties.

                                Show all comments
                                • pro xu 03.25.2015

                                  At windows server 2008/2012  R2 power managent option set to value:High Performance
                                  There are 200% to 300% performance improvement.

                                • James Zhong 03.25.2015

                                  Hi pro xu, what CPU do you use?

                                • pro xu 03.25.2015

                                  @James Zhong
                                  E5-1620 @3.7GHz.

                                • Daniele Bonetti 03.26.2015

                                  Following your suggestion I discovered that one of my servers (the sql server!) was in the balanced power config.
                                  Setting it to High performance has given a real boost.
                                  For those in core edition look at powercfg -LIST command
                                  Thank you!

                                • James Zhong 03.26.2015

                                  Thanks Xu for sharing your performance optimization tips!
                                  See also: (Slow Performance on Windows Server 2008 R2 when using the “Balanced” Power Plan)

                                • Randy Jean 09.22.2015

                                  "According to our research, some XAF applications are started significantly faster when built with the x86 target platform."
                                  Lost a bit of time after changing this for an ASP.Net app.  Dbupdater then reported "could not load file or assembly incorrect format" - took me a bit to backtrack and realize I had flipped my build to target x86 so beware of some of these tips.

                                • Anatol (DevExpress Support) 09.23.2015

                                  By default, DBUpdater is built with the Any CPU target platform and cannot load x86 assemblies when launched on x64 machines. To solve the issue, recompile it with the x86 platform, as described in the DBUpdate.exe on x86 application using Microsoft.Jet.OleDb.4.0 provider ticket.

                                • Randy Jean 09.23.2015

                                  Thanks Anatol.  In hindsight, this was an impetuous move on my part anyway as compiling ASP.Net app for x86 would limit the amount of memory that could be addressed in the app pool so I just flipped this back to Any CPU on my web project.

                                • Anatol (DevExpress Support) 09.24.2015

                                  OK. It is worth saying that this suggestion may be helpful only in WinForms. I apologize for not mentioning this in the article. I have updated it now.

                                • José Sanz 09.30.2015

                                  Please could you explain little bit more about the practical implementation of Miscellaneous #2? Thanks.
                                  2. You can reduce the loading time of your XAF modules (including <AppName>.Module, <AppName>.Module.Win and <AppName>.Module.Web) by overriding the GetDeclaredExportedTypes and GetDeclaredControllerTypes methods in their ModuleBase descendants. By default, these methods use reflection to go through all assembly types and find the declared controllers and business classes. If you override them and return lists of the module's business classes and controllers without calling base methods, these methods will be executed significantly faster.

                                • Willem de Vries 10.01.2015

                                  Is it possible to retain the results of the activities during loading time, so that we can use this information to code it during finalization of a certain version?
                                  How is this suggestion implemented in the OOB modules from DX?

                                • Anatol (DevExpress Support) 10.01.2015

                                  @José: You can see examples in our modules' sources. For example, the following code is used in the Audit Trail module:

                                  protected override IEnumerable<Type> GetDeclaredExportedTypes() { return AuditDataItemPersistentType == null ? Type.EmptyTypes : new Type[] { AuditDataItemPersistentType }; } protected override IEnumerable<Type> GetDeclaredControllerTypes() { return new Type[] { typeof(AuditInformationListViewRefreshController), typeof(AuditInformationReadonlyViewController), typeof(AuditTrailListViewController), typeof(AuditTrailViewController) }; }

                                  @Willem: To process your post more efficiently, I created a separate ticket on your behalf: T295848: Is it possible to retain the results of the activities during loading time. This ticket is currently in our processing queue. Our team will address it as soon as we have any updates.

                                • José Sanz 10.01.2015

                                  But should I return all my controllers writing all of them manually in the overrider method, or just a few of them?

                                • Anatol (DevExpress Support) 10.05.2015

                                  You need to return all controllers that should be included to your application. A controller that is not specified there will not be included.

                                • Stepan Lauryn 10.21.2015

                                  How set ObjectMethodActionsViewController.Enabled false? I did not find. Can you help me?

                                • Anatol (DevExpress Support) 10.21.2015

                                  You can set this property in any method called when your application is started. For example:

                                  public class Program { [STAThread] public static void Main(string[] arguments) { DevExpress.ExpressApp.SystemModule.ObjectMethodActionsViewController.Enabled = false;
                                • Stepan Lauryn 10.22.2015

                                  Thank you.

                                • Konstantin B (DevExpress) 05.18.2016

                                  Starting with version 16.1, you can enable the Application Model caching using the XafApplication.EnableModelCache property. When the cache is enabled, the Application Model content is only generated when the application is first launched. It is then cached to a file and this cache is used to reduce the startup time for future app execution. I have added this tip to the Miscellaneous section.

                                • Martin Praxmarer - DevExpress MVP 05.18.2016

                                  Oh that sounds interessting - how this this differ to ModelAssembly file?

                                • Konstantin B (DevExpress) 05.18.2016

                                  The ModelAssembly file is an assembly providing the Application Model object implementation based on the IModel...  interfaces, while the model cache file contains the entire model structure in an XAFML format. When the cache is enabled, Nodes Generators and Generator Updaters will be executed and the Model.Cache.xafml cache file will be created only when the application is started for the first time. Note that the first startup can take more time than usually. However, the time of subsequent startups will be reduced, because the Application Model content will be recovered from the cache. The startup time improvement is noticeable in applications with hundreds of business objects, and is about 30% in our tests. The cache is recreated when the version of any application module is incremented (i.e, when you update the deployed application). 

                                • Martin Praxmarer - DevExpress MVP 05.18.2016

                                  Great - seems like somthing similar was introduced be xafari recently :)

                                • Alex Miller 05.18.2016

                                  So this cached file with be the equivalent of the merging of the platform agnostic model and win model? This doesn't affect user modification in the regular Model.xafml file?

                                  So this cached file will only be regenerated when the DB Schema will change or when the file is deleted?

                                  Technically we could provide that cached file with our installer no?

                                • Dennis (DevExpress) 05.18.2016

                                  @Alexander, Noxe and others: we hope to address this and other questions in the upcoming blog post. Please subscribe to our team blog, stay tuned and thanks for being our customers!

                                • Dennis (DevExpress) 05.24.2016

                                  @Alexander, Noxe: I've answered your questions on this feature at Feel free to discuss it more in comments to this blog post.

                                • Chris Royle (LOBS) 11.22.2017

                                  With regard to 3.2, it's not entirely clear to me which types should be returned by the GetRegularTypes method override.....

                                  I've looked at the documentation link and this mentions "business objects, DbContext descendants, Controllers, List and Property Editors, etc."

                                  The example above does not include the controller in the GetRegularTypes return... so perhaps the documentation is incorrect on this point ?

                                  The "etc" part of the documentation is also a little vague.... should the module type be included, should the updater type be included, should enums referenced by the BOs be included (e.g. so that these can be translated) ?

                                  Is there any example of performance gain changing from reflection gathering to manually maintaining these overrides ?

                                • Alex Miller 11.22.2017

                                  Hi Chris,

                                  I don't override GetRegularTypes , but you got me a little curious. I've overridden it in my default and largest module  and it seems base.GetRegularTypes() returns every type possible in the module (350+). I've quickly measured with a StopWatch (sorry no time for a fancy BenchmarkDotNet) and I got around 48ms on release built with no debugger attached. Simply returning the array of all types takes .1ms so there's definitely a benefit here. But listing all type explicitly is also a maintenance nightmare!

                                  Perhaps use the non overridden GetRegularTypes on development and when preparing the release, override with the latest types list. Or maybe these are already or could be cached , so only the first launch will be affected...

                                  I'm using GetDeclaredControllerTypes and GetDeclaredExportedTypes for convenience, because I can easily comment out problematic controllers and types when developing. I've never bothered to measure the performance improvement.

                                  When I have some time, I'll measure the others GetXXX overrides to see the benefits and post my results here.


                                • Manuel Grundner [DevExpress MVP] 11.22.2017


                                  For the maintainability nightmare: normally I use a separate static ExportedTypes class with a static types[] to keep the module clean. I also do this for Models, Controllers and Editors.
                                  For Editors it's esp helpful, cause I maintain the registration in the editor itself, and call it from a static Editors class, so I can keep track of them easily.

                                  for the exported types I use a simple script that outputs the types from the base.GetRegularTypes() as a type[] and modify the source in release mode before I deploy a new version.

                                • Chris Royle (LOBS) 11.22.2017

                                  @Alex, @Manuel thanks for replying.

                                  I'm not sure that reflection (in general) is the bottleneck that it used to be in 'the olden days' - 48ms vs 0.1ms cited above is many multiples of improvement, but in reality not that great given the maintenance headache which it introduces.

                                  The benchmark above might cover the reflection time only, but not the cost of processing 350 types rather than x relevant types ?

                                • Manuel Grundner [DevExpress MVP] 11.22.2017

                                  @chris you are right, but multiply it by module. So for 5 modules + win its 10*50ms eh half a second.

                                • Alex Miller 11.22.2017

                                  @Manuel Thanks for the input and good ideas. The separate static ExportedTypes will definitely cleanup the module. The script and the source modification at release is exactly what I had in mind. I created such a script for my benchmark test. Now I just need to tidy this up a little.

                                  @Chris @Manuel To me, every millisecond saved at application startup is worth a little headache. I didn't know it was that much time because I would've definitely looked into this earlier.

                                • Chris Royle (LOBS) 11.22.2017

                                  @Alex, I'm curious to know what improvements you realise in terms of start-up time reduction. Without concrete information it's hard to know where the balance is.

                                  Sure we'd like this to be as fast as possible, but also have to balance the cost of the changes + ongoing maintenance as these are transferred to the customer. We have a lot of core modules, where it'd make sense to invest the time improving these. These are reasonably static in terms of xaf related classes. The customer specific modules, less so.

                                • Alex Miller 11.22.2017

                                  @Chris I'm cooking an automated solution that should (hopefully) completely remove the maintenance nightmare. I have a detailed application startup metric in my app and once i'm done, I will post the explicit declare vs reflection startup times results. Hang on....

                                • Alex Miller 11.23.2017

                                  @Manuel and @Chris I've posted in a separate ticket an automated solution to the maintenance nightmare. See here:

                                • Dennis (DevExpress) 11.23.2017

                                  @Alex and Manuel: Thanks for sharing your experience with the XAF community.
                                  @Chris: I hope that your question on the performance was answered above. As for the documentation, I will answer you in the Questions on the GetRegularTypes method override thread as soon as I can.

                                0 Solutions

                                Creation Date Importance Sort by