Firstly, premature optimization is the root of all evil . That is, first check your code and make sure that sorting is the one that actually takes the most time. If another part of your critical code takes 80% of the execution time, you will first get dramatic performance improvements by optimizing this.
Given you have 5 elements, the point is pretty much controversial. Any algorithm you use (except bogosort: D) ββshould have a fairly constant runtime, unless you run the algorithm several hundred times per second or more.
Secondly, if you still want to optimize the search, if you know for sure that you will always have 5 elements, the best method is to hard code the comparisons (mathematically it can be proved that this method is optimal, ensuring the minimum number of operations performed in the worst case - we had it as a laboratory application at the university). The same thing happens if you have less than five elements, but the algorithm becomes prohibitive for writing and executing, if you have more than seven elements - the logic is confused for writing and subsequent work, so your code will be difficult to maintain.
Let me know if you need help writing the hardcoded algorithm itself (although I think you should find an implementation and theory online).
If you do not always have five numbers (or for some reason want to avoid hard comparisons), use the sorting provided by the library. This page concludes that stl sorting is optimal in terms of time (not just the number of operations performed). I do not know which implementation was used for the search.
source share