Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

We're doing an integration project where we receive a lot of code values from a webservice.These codes need to be mapped to a user-friendly, translateable text in a visualforce page. We've set up a custom label for each possible code.

The straight forward solution to the mapping is probably a long if else structure, but is that the most performance efficient ?

public static string getTypeLabel(String code) {
    if (code == '1') {
        return Label.TypeONE;
    } else if (code == '2') {
        return Label.TypeTWO;
    } else if (code == '...') {
        return Label.TypeStuffInBetween;
    } else if (code == 'n') {
        return Label.TypeN;
    }
}

I considered that the above approach takes more runtime execution time, specially if there are a lot of possible if statements. I thought that shifting the mapping mechanism to using the internal Map:key-value mechanism could bring improvement.

private static Map < string, string > TYPE_MAP = new Map < string, string > {
    '1' => Label.TypeONE, 
    '2' => Labem.TypeTWO, 
    '...' => Label.TypeStuffInBetween, 
    'n' => Label.TypeN
};
public static string getTypeLabel(String code) {
    if (TYPE_Map.containsKey(code) {
        return TYPE_MAP.get(code);
    } else {
        return code;
    }
}

My initial thought was that this would reduce execution time, but maybe I'm know too little of the internal stuff for this to actually be true. But we have actually implemented it like this, would a class with LARGE (10-100 items) hardcoded map declarations possibly be not more efficient at all,does the use of containsKey() and get() on large maps limit or reverse the performance gain?

I'm not quite sure how to properly evaluate this, so I turn to you :)

share|improve this question
4  
I can't speak to performance, but I think the mapped solution is WAY more maintainable and more elegant. –  Mike Chale Dec 19 '12 at 13:07
add comment

2 Answers 2

up vote 6 down vote accepted

On average, the if/else solution needs to do n/2 comparisons, while cheap and fast it's O(N). A map lookup in a hashmap might have slightly more overhead for small amounts of data, but it scales O(1) which means it's guaranteed to be faster past a certain amount of data.

I agree with the comment that it's a more elegant solution as well. I can't comment on when or even if (in practice) it'll actually be faster in Apex, but I'd definitely recommend the map-approach.

A very apex-specific aspect of this is that it's probably easier to create testcases with better code coverage using the map-approach, since you wouldn't actually have to run all possible map-values in your test-case to get your code coverage up, and if you wanted to it'd be easier to since you have them accessible in a nice data structure, not hard-coded.

share|improve this answer
add comment

I tend to think in these cases that in terms of performance, the time taken to run the code is negligible in comparison to the time to taken to send requests and receive responses and the like.

With this in mind, my approach would be to opt for the most maintainable solution, and to this end I would leverage Custom Settings if possible. If you create a list-type custom setting, you can then get a record by name, and you can get a map of all the values in one go. It might take some extra work on your part to use a datamodel (I don't know know what type Label.TypeN is) but in terms of ongoing maintenance it would much easier as anybody with access to the settings could modify the map without having to edit code.

share|improve this answer
1  
I originally wanted to use custom settings, but as the output should also be translation capable, we needed custom labels. I did not found a way to return custom labels from custom settings without apex in between, so I considered it would be better to handle it in Apex directly. There is also a hard limit on total custom setting size (cache) which in the (very) long run may become a show blocker. –  Samuel De Rycke Dec 20 '12 at 6:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.