Designing for Performance Part 5

[Chris Pearson]

Continuing where we left off with our designing for performance series, let's discuss a few common pitfalls that lead to poor performance. These come straight from a SN webinar delivered by their Account Escalation Engineering (AEE) team.

Another common pitfall they see are Glide Record queries which don't include limits on the number of records returned from the query. I have to say, I often leave this best practice out of my code too. Sometimes looking in the mirror is hard. What tends to happen is you write your code but don't take into account the number of records a table may have in PROD vs DEV or that you don't consider the future growth of table size over time. This can lead to inefficient code.

In a real-world example, the AEE team described a custom which had a slow custom business rule which was impacting scheduled jobs and imports. They had added logic which simply needed to check for a single matching row on the many to many table defining group membership (sys_user_grmember). If we have one, proceed. But their code didn't have a .setLimit(1) line in the query. The query generated about 7 HOURS of processing time each day and each execution returned approximately 71,000 rows. Once the setLimit(1) line of code was added to the script, it ran incredibly efficient, saving 7 hours of processing time and over 1.5 BILLION excess rows returned in the query which didn't need to be there.