Facebook

Summer 14 Describe Patterns

On each Force.com release, developers eagerly look through the release notes for exciting new features. I’ve found that the things that excite me most often aren’t the same things that thrill others. I often get most excited about small changes – sometimes they can have a huge impact on software design patterns.

This summer, the biggest feature for me is the elimination of Describe limits. This eliminates a huge Catch-22 when developing on the platform. On one hand, good Apex code is supposed to respect field level and object security. But the previous Describe statement limit made it difficult and sometimes impossible to do so on larger applications and systems, where the number of fields processed in an execution context could easily exceed the available limits.

The elimination of Describe limits does, however, raise an interesting question. How does this change impact design patterns and could other limits come into play? Or put another way – how costly are Describe calls in terms of CPU time?

Prior to now, the best design pattern for using Describe statements involved caching each Describe call so that you could at least ensure that you don’t call getDescribe on a field more than once in an execution context. The design pattern looked something like the getDescribeInfo function below, where the parameters are the field name and SObjectField token for the desired field:

private static Map<String, Schema.DescribeFieldResult> fieldDescribeCache = new Map<String, Schema.DescribeFieldResult>();
private static Schema.DescribeFieldResult getDescribeInfo(String name, SObjectField token)
{
    if(!fieldDescribeCache.containsKey(name)) fieldDescribeCache.put(name, token.getDescribe());
    return fieldDescribeCache.get(name);
}

Does it still make sense to use this kind of pattern? Or should you just call getDescribe() whenever you need describe information?

To find out, I did some benchmarking using the techniques described in chapter 3 of the second edition of Advanced Apex Programming.

I found that the approximate cost of a Describe statement is about 3 microseconds. This looked pretty fast to me. Can the earlier design pattern, with its cost of an additional function call and map lookup, be any faster?

The answer, as it turns out, is no. The overhead of caching and looking up data exceeded any benefits that might have come from avoiding the extra Describe calls.

Further testing showed the same results with SObject describes as field describes.

I don’t know if Describe calls on summer 14 are fast because work went in to optimize them, or because the platform is now caching describe data internally for you, but it doesn’t really matter. It seems clear that going forward, the optimal design pattern for describe statements is to use them inline as needed.

2 comments to Summer 14 Describe Patterns

  • Hi Dan

    Thanks for posting this as I was curious about this myself. Did you try this on Schema.getGlobalDescribe() to see if that call was worth caching?

    • Dan

      I hadn’t checked, but did now. Schema.getGlobalDescribe is an expensive operation (looks like about 2.5ms), and is not cached. So if you find yourself needing to use it often, you should cache it.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>