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'.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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'.