KB Article A657
Visible to All Users

Optimization best practices

Description:
There are several techniques which can help in improving the performance of an application which uses persistent objects.

Answer:
How to get the best performance is one of the most common questions and only general advice can be given on how to design persistent objects or even a whole application to get the best performance.
At the moment we are working on several applications and sometimes we test their performance using profilers - this is the most powerful technique that can be used when improving the performance of any kind of application.
Though, there are several things you should be aware of before you start working on performance improvements:
- We recommend creating a large number of objects within a transaction:

C#
Session.DefaultSession.BeginTransaction(); .... create a large number of objects and save them ... Session.DefaultSession.CommitTransaction();

Note: When XPO saves an object it starts an implicit transaction if there is not one already started. That is necessary to save complex objects: a contact with its addresses (which are aggregated objects), a company with its employers, etc. You don't need to worry about saving such types of data as XPO manages them. This though may slow your program down when you are saving a large number of objects: each object saved has a start and commit for an implicit transaction.
- Unnecessary actions when creating or saving objects may be another cause of poor performance.
- At the moment the objects reading performance looks similar to the ADO.NET datasets performance. The total time taken to load a collection or a single object consists of two parts: the time which a DataReader requires to fetch the information from an underlying database and the time which XPO requires to create objects and copy values from the DataReader to the objects' properties. If you are planning to make a single user application consider using one Session to work with all the objects: every read object is placed into the cache and the second part of the loading won't be applied to those objects. The cached object can be removed from the cache only when nothing references it and there is a request from the operating system to release unnecessary memory. See our article "Performance Comparision" at for more details.
Note: If you are developing a multi-user application you can have trouble with this technique when fetching the latest information from the underlying database: you will get the cached information instead of the actual information from the database.
- If you are processing a lot of objects consider using the XPCursor to move through the objects' chain. Compared with the XPCollection the XPCursor splits all the objects into pages and works with one page at a time. This technique reduces the memory required to process all the objects and can improve the application's performance. Consider using the PageSelector class to split all the objects into several pages and then process the objects in several threads simultaneusly.
These are the most typical solutions which can help, but remember that there are many other factors which can have a great influence on your application.

Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.