A while ago, I asked about this:
And I got some great feedback from everyone.
I'm working in a real world scenario now and proposing an org move their 78 wf rules and 28 process builders - on one object - into Apex for the most part, leaving some in for things like scheduled actions and outbound messages.
I have worked out some patterns for encapsulating logic into common interfaces and have been doing some basic testing in a dev org to make sure it's not adding a ton of overhead. The plan is to put some controls in CMDT to manage disabling automation.
What I'm seeing, though, is that with the overhead of loading the trigger, querying for related objects, dynamic assembly of the field changes, the relative performance between workflow rules and triggers is not quite as far apart as reporting might suggest. I want to make sure as I'm explaining my recommendations to the client, I'm not promising something that can't be delivered.
I know that my testing may be a bit oversimplified, but does this make sense? If I'm developing an apex framework or needing to reference related parent records (thus using SOQL), it seems logical that it adds overhead in execution time and possibly heap size. So, won't I be losing a fair amount of the performance gains that many have identified in various blogs?
I realize fully there are other excellent reasons to make a choice to move this to apex (order of execution, salesforce limits, recursion, consolidation of technologies, testing). I just want to make sure that if we proceed on this, I've set expectations appropriately.
For those who have done similar work - did you actually realize a meaningful gain in performance? Or was the gain more in terms of other benefits?