I'm adding a non-strafe mode.
Option 1: Take the walk animation, go into blender, flip all keyframes and apply them into various directions
Option 2: have only 1 walk animation, add a bunch of lerp functions and directional stuff to turn the player's mesh
which one is lighter and more performing?
TLDR; it likely doesn't matter, you should use the one that is easier for you, and gets you past this step sooner.
It's a hard to tell exactly what you're trying to do, but it seems like you're concerned with the performance impact of basic arithmetic operations like transforming position and rotation (animations are essentially the same thing).
It's common to worry about these when just getting into development, but the reality is that it's extremely rare that the operations are so complex that one method is noticeably better performing than another. The common saying is "premature optimization is the root of all evil".
If you want to know anyway (I understand) then the best option is always to make a test. Make a separate project or script that does your math operation in a huge loop, like 1 million iterations, and measure the clock time before and after. You will likely find that the single operation itself takes so little time that it's not worth worrying about.
EDIT: The above approach is best for getting things done, but for anyone who might be using Unity, whose only task is to improve performance in a UI with an animated element, this video may prove helpful (relevant section starts around 24 minutes): Ian Dundore - Squeezing Unity - Unite Europe 2017
What do you think the engine does with the key frames? That's right it interpolates them. So there is math going on anyway.
Thus, unless the Option 2 is overly complicated it is likely to not be a reason to worry.
So, I'll echo Wiley Rush advice: do it the way find it easier.
Afterwards, if it turns out to be a performance problem, you might try the other way and compare and see which is actually better in practice. But if it is not a problem, stick with what is easier to do.
With that said, I want to give you more options:
Option 3. Assuming you need a simple transformation you might apply it to the parent Node3D (Godot 4)/Spatial (Godot 3), this will do for mirror, rotation, scaling, or skewing transformations.
Option 4: If you can do the math in Godot to do or modify the animation on the fly, then you can also have Godot save the modified animation with a tool script running in the editor... So when ruining the game, it is the same as if it were an imported animation.
Option 5: You can encode the key frames in a texture (e.g. the x coordinate is time, and the y coordinate is vertex index, the RGB channels are XYZ positions/displacements) so that you can use a custom shader do the animation entirely in GPU. This will win the performance battle (useful in particular for crowd animations), but it is worse usability as we don't have tooling for this.
I don't know exactly what you are doing (in particular, why my Option 3 is not your Option 1), but we had plenty of questions about how animations work behind the scenes in this site, and if it is not covered, go ahead and ask.
