When used correctly, Calculated Attributes enhance the apps by handling basic calculations at run time; Used poorly and they will damage your app performance. In this use case I walk through a sample app based on a real-world problem to explore the performance issues and a couple of strategies to improve performance to the correct standard. I appreciate any feedback and hope this helps some Mendix devs!
This entry started as the first in my next series that I planned about reporting with Mendix, but when capturing my screenshots I realized my example was so poorly designed in a working, production application that I needed to address it. While I don’t have the story prioritized to actually do the work to fix it versus competing higher priority issues, I’m going to explain what I did wrong in one of the first processes I ever wrote in Mendix and how I would design it differently had I followed my BI best practices and understood Mendix as well as I do now. Hopefully this comparison will help others who develop in Mendix when trying to optimize their application and look at each step more critically.
I was asked to help a fellow Mendix developer with some workflow issues and something stood out: There were a LOT of nested loops. Though preached (commanded?) by computer science professors as bad practice for very good reasons, we all know in the 'real world' outside of the walls of academia that sometimes you require the kind of result that can only be achieved by comparing multiple lists as they relate to each other. This creates a massive amount of overhead on a single-threaded application and can render an application useless if those lists are sizable. Sure, domain modeling is often to blame, but tools like what Mendix provides are supposed to make it easier for non-developers to do this kind of thing. There is a better way, and Mendix provides a set of actions to help you deal with these in a more efficient way: List Operations.