So which approach is faster? Did anyone test that? It's just another aspect to look at it, which might be relevant in some cases. I used write assembly and when I read code like this I compile it to machine code in my brain. One of greatest performance tweaks can be done with ugly ifs. End user will thank you. Next person taking over your code - not so much
I ran the tests out of curiosity using Java 11 and jmh looking at throughput...
Three implementation, if else if..., map (hashmap) and a switch.
With one notable exception, the results were as I had expected:
The if else if... approach became slower for matches against the "later" input options i.e. proportional to the number of comparisons performed before a match was found.
The map approach provided constant performance for all input options,
The switch approach also provided constant performance for all input options, not expected but I'll assume some compiler optimisations there.
The switch approach was slightly faster than the map approach.
The switch and map approaches were both slower than the if else if...until you test the 3rd or 4th input options respectively.
The if else if... approach degraded in performance until the 11th input when it improved slightly and then continued to degrade again. (I can't explain this).
In general, I prefer the map approach over a large if else if... block and 3 or 4 branches seems like a nice rule of thumb for when you might want to look at moving to the map or switch approach, both in terms of performance and readability, IMHO.
A map or associative array of some kind probably makes heap allocations and has plenty of ifs in its internal implementation. So I would hazard a guess it is probably a lot slower than just using ugly ifs.
Just to add some clarification, this Map.of method returns an immutable map of defined size, so there’s not a great deal of heap allocation.
Besides that I usually try to optimize code for readability, even if it’s at the expense of a few microseconds.
I also think that being a static content Map the compiler would probably do some kind of optimizations, but that’s only my guess and trust in the bright JDK engineers.
But I’d like to see that kind of performance comparison, always good to put theory to practice!
Fair points. I guess it also depends what you're trying to do.
If you're writing kernel code, or stuff for embedded systems, the issue of lots of branches can itself be an issue - from a performance point of view. Data oriented approaches might focus on removing branches in the first place by organising the layout of data and making the code run better by processing on 'chunks of stuff'.
So which approach is faster? Did anyone test that? It's just another aspect to look at it, which might be relevant in some cases. I used write assembly and when I read code like this I compile it to machine code in my brain. One of greatest performance tweaks can be done with ugly ifs. End user will thank you. Next person taking over your code - not so much
I ran the tests out of curiosity using Java 11 and jmh looking at throughput...
Three implementation,
if else if...,map(hashmap) and aswitch.With one notable exception, the results were as I had expected:
if else if...approach became slower for matches against the "later" input options i.e. proportional to the number of comparisons performed before a match was found.mapapproach provided constant performance for all input options,switchapproach also provided constant performance for all input options, not expected but I'll assume some compiler optimisations there.switchapproach was slightly faster than themapapproach.switchandmapapproaches were both slower than theif else if...until you test the 3rd or 4th input options respectively.if else if...approach degraded in performance until the 11th input when it improved slightly and then continued to degrade again. (I can't explain this).In general, I prefer the
mapapproach over a largeif else if...block and 3 or 4 branches seems like a nice rule of thumb for when you might want to look at moving to themaporswitchapproach, both in terms of performance and readability, IMHO.A map or associative array of some kind probably makes heap allocations and has plenty of ifs in its internal implementation. So I would hazard a guess it is probably a lot slower than just using ugly ifs.
Just to add some clarification, this Map.of method returns an immutable map of defined size, so there’s not a great deal of heap allocation.
Besides that I usually try to optimize code for readability, even if it’s at the expense of a few microseconds.
I also think that being a static content Map the compiler would probably do some kind of optimizations, but that’s only my guess and trust in the bright JDK engineers.
But I’d like to see that kind of performance comparison, always good to put theory to practice!
Fair points. I guess it also depends what you're trying to do.
If you're writing kernel code, or stuff for embedded systems, the issue of lots of branches can itself be an issue - from a performance point of view. Data oriented approaches might focus on removing branches in the first place by organising the layout of data and making the code run better by processing on 'chunks of stuff'.
I second that.