The Hidden Cost of size() == 0, Apex Performance Tip You Can’t Ignore

Salesforce Apex developers use Lists, Sets, and Maps as their regular collection tools. Before starting your work, you need to check if your collection contains any empty elements because you will be looping through queried records, handling user selections, or transforming data.

That’s when the classic Apex developer debate kicks in:

🤔 Should I use isEmpty() or size() == 0 to check if a List, Set, or Map is empty?

The two methods appear identical at first glance because they both check for an empty collection. The two methods differ fundamentally in their readability and performance characteristics, especially when used in high-volume operations like Batch Apex, Triggers, or real-time integrations.

Choosing the right method can help you write cleaner, faster, and more maintainable code. When you’re dealing with governor limits in Salesforce, every millisecond and line of logic counts.

In this blog post, we’ll break down the subtle (and not-so-subtle) differences between isEmpty() and size(), show you how they perform, and help you decide which one to use and when.

Let’s jump into the ring.

The Basics: What Do These Methods Do?

isEmpty()

• Returns true if the collection contains no elements.
• Available for List, Set, and Map.
• More readable, more intuitive.

if (myList.isEmpty()) {
   System.debug('List is empty');
}

size()

• Returns the number of elements in the collection.
• Can be used to check if the collection is empty via size() == 0.

if (myList.size() == 0) {
   System.debug('List is empty');
}

The Showdown: Readability vs Performance

Readability Champion: isEmpty()

Let’s be honest — this is much easier to read:

if (myMap.isEmpty()) {

VS

if (myMap.size() == 0) {

Especially for junior developers or someone scanning code quickly, isEmpty() clearly communicates intent. It reads like natural language.

Performance Champion: isEmpty()

You might think size() == 0 is faster, but here’s the kicker: isEmpty() is actually faster, especially in tight loops or large datasets.

Why?

• isEmpty() typically performs an internal boolean check.
• size() must calculate and return a number, which is then compared to 0.

While the difference is tiny in small scripts, it matters in bulk processing, Batch Apex, or real-time integrations.

Benchmark Test in Apex

Here’s a test you can run to see the difference in execution time over 100,000 iterations:

List<Integer> testList = new List<Integer>();
for (Integer i = 0; i < 100000; i++) {
    testList.add(i);
}

// isEmpty check
Long emptyStart = System.now().getTime();
Integer emptyCount = 0;
for (Integer i = 0; i < 100000; i++) {
    if (!testList.isEmpty()) emptyCount++;
}
Long emptyTime = System.now().getTime() - emptyStart;

// size() check
Long sizeStart = System.now().getTime();
Integer sizeCount = 0;
for (Integer i = 0; i < 100000; i++) {
    if (testList.size() > 0) sizeCount++;
}
Long sizeTime = System.now().getTime() - sizeStart;

System.debug('isEmpty() duration: ' + emptyTime + ' ms');
System.debug('size() duration: ' + sizeTime + ' ms');

Sample Result:

isEmpty() duration: 17 ms
size() duration: 28 ms

Your numbers might vary, but isEmpty() is consistently faster because it doesn’t compute the full size it just checks if the count is zero internally.

Real-World Use Cases

Use isEmpty() to guard logic

if (!accountList.isEmpty()) {
    update accountList;
}
Cleaner, faster, and tells the story right away.

Not Ideal: Overusing size()

if (accountList.size() > 0) {
    update accountList;
}
Works, but adds unnecessary computation and noise.

When size() Is Actually Needed

Sometimes, you do need the number of elements: System.debug('Processing ' + caseMap.size() + ' cases');
In these cases, size() is the right tool.

Final Verdict: isEmpty() Wins

If you’re only checking whether a collection has any values, always use isEmpty(). It’s:

• More readable
• Better performance
• Less prone to coding mistakes like = 0 vs == 0

Keep size() for when you need the actual count, not just presence.

#Salesforce #SalesforceDeveloper #Apex #CleanCode #ApexPerformance #DevBestPractices #CodingTips