You can use an int rather than a class as a template argument.
If appropriate, you can specialize on values of that int, which seems like what you would want to do for method and maybe for order.
If you don't also do some extra work, that would change your calling syntax:
You can add layers of code (usually with big switch statements) to convert from one calling syntax to the other. That might be worth it depending on where / how the calls are used.
It may seem the big switch statement would add the same run time overhead that you're trying to remove, and if you aren't careful it might.
When instantiating an inline function, where argument values are know at the call point, the compiler will bring that knowledge into the inline function. So many constructs that look like run time "if" or "switch" will actually be handled as compile time "if" or "switch". You can use this effect:
To write the layer that changes call syntax without the run time overhead it may seem to have.
To specialize less and write code templated on Method and/or Order that seems to do run time checks, but the compiler will effectively specialize.
To specialize only linearly on each of Method and Order, not combinatorialy on both (the compiler would instantiate combinatorialy specialized versions as used).
Exactly how to do any of that in your problem space depends on details you haven't provided. It may be fairly obvious or quite tricky. (But if you provided such details, that might also stop me from providing more specific help, because your problem space is quite close to something I work on professionally, subject to non disclosure).
Often, there is a big challenge in forcing the compiler to convert run time "if" operations into compile time "if" operations early enough in the optimization process to allow other optimizations that depend on that conversion. I have often used complicated extra layers of templates to convert what is logically a compile time "if" statement into a template instantiation, that the compiler is forced to resolve early in compile time, allowing subsequent optimization of the result.
gcc has some added features (not part of the C++ standard) for coding compile time "if" statements more directly. I think that is a better approach, but I can't use that myself because I must code for multiple compilers. Note I do NOT mean "#if". A preprocessor "if" is much too early, just as a run time "if" is much too late.
When I work on such problems, I generate asm output from the compiler and look at key points in the code to see whether the compiler really did convert the important tests from run time to compile time. Of course, if you don't know x86 assembler, doing that could be a lot harder.