Lab briefing · A rule, and its performance

Write a validation rule, load a thousand records against it, MEASURE what it cost — then rewrite it so it does not. The rule should be a realistic one: something that reads a related record or a child collection to make its decision, because that is the shape that scales badly and it is the shape people write naturally. Give it a message that tells the user what to do, per Lesson 3 — that half is graded too. Then measure, and the measurement is the point. Save one record: note the time. Load a thousand: note the time. Divide, and see whether the per-record cost is flat — and where it is not, you have found the loop. Then rewrite. Move the lookup out of the loop, or read a value already on the record, or guard the expensive part behind a cheap condition. Measure again and write both…

In this module: Module 13 · Groovy in Application Composer

1. 1Where Groovy runs, and where it does not
2. 2The language subset, quickly
3. 3Validation rules that help rather than annoy
4. 4Triggers and the order they fire in
5. 5Object functions and reuse
6. 6Performance: the rule that runs a million times
7. 7Debugging without a debugger
8. 8What breaks: three Groovy failures
9. 9Lab briefing · A rule, and its performance