Performance of OCL queries

OCL is a very powerful tool in Vertec – you can query the entire Object Model without worrying too much about technical details (e.g. associations or calculating derived attributes such as the VAT amount on an invoice).

However, there is also a significant disadvantage: OCL is applied directly to the Vertec objects, and for this to work, they must first be loaded into the session’s memory. The more objects and the more complex the query, the more performance it costs.  

Therefore, with every OCL expression you should consider:

1. Is OCL the right way for this query? To answer this question, you should look at the article Performance-optimized access to vertec objects.  
2. If so, can I reformulate the OCL expression to get the same result with fewer objects in memory?

The OCL principle is:

Select on as small a quantity as possible and only then navigate to the larger quantity.

As an example, let’s take the following OCL expression:

openService->select(project.type.designation='Internal')

This expression is correct, and if executed globally, it returns all open services on projects with project type "Internal".

However, it is highly inefficient because it first loads all open services in the system in the memory (including those that are not on internal projects) and only then filters for those on internal projects.

But we are not really interested in the services on the projects that are not internal. How could we get the same result without loading all the services not needed?

It is important to always start at the smallest place, i.e. where there is the least number of objects. In this case, these are the project types. If you take the one labeled "Internal" and load the associated entries from there, only what is really needed will be loaded at the end, with the same result:

projecttype->select(designation='Internal').projects.openServices

The beauty of OCL is that you can navigate in all directions through the Model. So if possible, you should always navigate through the object system instead of filtering lists. Don’t load a lot of objects and then narrow it down, but come from the other direction and load only the objects you need.  

For more performance tricks around OCL, see Performance-optimized access to vertec objects.