The real answer here is: unless you identified a real performance
problem; you do not worry about "performance" issues within your code.
Meaning: you did some profiling and found that a certain piece of code that is called many millions of time during a short period of time takes "too much" time. Then you would probably start by writing small examples, trying to do reasonable benchmarking to enhance your solution to meet some "target" performance.
But be assured that the difference between switch/if/if-else is in the range of nano-seconds; and you have no idea what the just-in-time-compiler is doing to your code anyway. To the contrary: the JIT is great about optimizing "normal, ordinary" code. When you start to be "clever" and "optimize" on the java source code level; chances are that you make it harder for the JIT to deal with your code. So, in the end; your java code looks "faster"; but the real execution time is worse than before.
Thus: you focus on writing code that is readable. And alone the fact that you talk about "10 parameters" that need to be treated is bad practice.
Long story short: focus on good design; for example based on SOLID principles (of course avoiding real performance pitfalls). That will allow you to change your implementation later on; in case you are running into real performance issues.
As of now, you are wasting your energy on the wrong topic.