Better performance between if-else-else-… vs hardcoded maps

Question

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 :)

Answer 1

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.

Answer 2

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.