Question

Does the Mendix server experiences increased performance while performing filter actions on sorted lists?

0

Hi Mendix experts, When I do a database retrieve on a table with an index and in the database retrieve I use the attribute that is specified in the index, the database is able to use that index for increased performance. I am wondering whether the Mendix server also experiences increased performance from sorted lists when doing a list function. For example when I have a big list of objects in a microflow sorted on attribute A and in the next action I do some filter list action of that sorted list filtering on attribute A. It makes sense that in this case the Mendix server benefits from the sorted list, but im not sure. Thanks! Tim

asked 2025-07-28

Tim Speksnijder

2 answers

1

Hi Marcian,

Thanks a lot for your extensive answer. I now understand why the Mendix server does not benefits from pre-sorted lists while filtering in a microflow. Your answer was very helpful!

Best regards,

Tim

answered 2025-08-21

Tim Speksnijder

Marcian-Petrut Bondoc-Popescu · Accepted Answer · 2025-08-21

Hi Tim,

That's an excellent question that gets to the heart of understanding Mendix performance.

The short answer is no, unfortunately, the Mendix server does not get a performance increase when filtering a list that has been pre-sorted in a microflow. A "Filter" or "Find" list operation will always iterate through the entire list from start to finish.

When you perform a list operation like Filter by expression in a microflow, you are working with a list of objects held in the Mendix server's memory.

Let's take your example:

You have a large list of objects in memory.
You use the "Sort" activity to sort this list by Attribute A. This action creates a new, sorted list in memory.
You then use the "Filter" activity on this sorted list, with a condition involving Attribute A.

The "Filter" activity will perform a linear scan. It starts at the very first object in the list, checks if it matches your filter criteria, and if it does, adds it to a new output list. It then moves to the second object, the third, and so on, until it has checked every single object in the list. The fact that the list is sorted doesn't allow the runtime to "skip ahead" or stop early, because it can't assume what the filter condition is (e.g., it could be a complex expression or even a < or > check where it might theoretically stop early, but the implementation doesn't do that).

Why This Differs from a Database Retrieve

This is fundamentally different from how a database works. When you do a Retrieve from the database with an XPath constraint (e.g., [AttributeA = 'SomeValue']), you are sending a query to the database.

If AttributeA has an index, the database's query optimizer can use that index (often a B-tree data structure) to find the exact records that match your criteria almost instantly, without having to scan the entire table. This is incredibly efficient and is the primary reason for indexing.