TLDR: You need to accept your leader's authority, but you should point out incorrect assumptions, provide feedback, attempt to establish standards and teach him no argument is often better than a faulty one
Follow the herd leader
Exactly as Fattie said in a comment, as a team you will often encounter situations that will require a decision to be made and often enough there is no time to ditch out all the details to make a perfect fact based decision. Often enough it doesn't matter what is a few ms faster and code style can be arguable. At some point someone needs to decide which solution to go for so the team can move on to bigger challenges. Once such a decision has been made, as a team member, you need to accept that decision and move on.
Responsibility of the good herd leader
BUT: it is your team leader's task to lead by example and "take the team with him", when he's making such authoritative decisions. He can either explain why he thinks something is better or decide by authority or by standard. Usually you want as much standards for such situations based on facts as possible, so situations like this can be quickly resolved by citing the standard and are avoided most of the time anyway as the standard is known.
If he argues unconvincingly or even repeatedly factually wrong that shows bad leadership skills and you should help him get better at it. That does require feedback.
Feedback
For instance, you can question his argument. If he says it is faster:
Is it really faster? Can you explain why? Last time we had something similar the other solution was faster. Look, I've got this similar test here...
Try to abstract away from individual things to general problems for which a standard way to solve them can be discussed, tested once and then widely applied.
If you don't have data ready when a decision is made, you can also bring it up in one of the next meetings.
I've read up/tested on lookup times of individual items in a linked list and a hash map and the hash map is always faster, maybe we should define a standard to always use hash maps for such problems from now on.
Pick your battles wisely. Don't try to fix some minor issue that only occurs once, after the fact, but try to get policies established that you can refer to. Note that performance isn't the ultimate measure, readability often trumps performance gains.
Don't attack the authority of your team lead, but try to support him:
Look, if you tell me this is the way we do things here for whatever reason, that's fine. But this is not faster for [reason], so if you want to squeeze out a little more speed, maybe we should give variant B a try.
Don't argue about "my variant" vs. "your variant", try to detach yourself from different options available. That way it is not as much between you and him, but about choosing the best option together.