Python size equals comparison efficiency

12>=12 # 44.3 ns
12>12 # 44.4 ns
12!=12 # 44.4 ns
12==12 # 44.4 ns
12<=13 # 46.8 ns
12<13 # 46.8 ns
10!=12 # 47.4 ns
12>=10 # 47.5 ns
12>=13 # 47.6 ns
10<=11 # 47.7 ns
10<=12 # 47.7 ns
12==13 # 47.7 ns
12>10 # 47.7 ns
10<12 # 47.8 ns
10==12 # 48.4 ns
10<11 # 48.5 ns

Sometimes I think it is necessary, but I feel it is necessary, because the obvious gap is large, there must be internal reasons, speculating on internal processing methods is also part of programming. And the big brother-level algorithm is worthy of reference.

Efficiency: the
same value> different values
not equal to different values> equal to different values

The same value is easy to understand, as long as the judgment symbol includes =, it is True, otherwise it is False.
Different values, including only =, is True, not only including = and excluding =, all need to be judged, but the need to judge is more efficient, which means that he It is a judgment to be processed first, and then to see which type of comparison symbol is, and only =, which is processed at the end.

if a == b:
	if '=' in sign:True
	else:False
elif a > b:
	if '>' in sign:True
	else:False
else:
	if '<' in sign:True
	else:False

The current speculation is like this, so let's verify it.

12>=13 # 46.8 ns F
12>13 # 46.8 ns F
12!=13 # 46.9 ns T
12<=13 # 46.9 ns T
12<13 # 47.7 ns T
12==13 # 47.8 ns F

Two greater than signs, on the contrary, the fastest result, the result is False,
not equal to,
less than or equal to

The above are almost all the results obtained in a period of time. There are True, False
and the determined as true is less than, and the determined as false is equal to, are the final results

Presumption:
Process 1, to determine the size of two numbers
Process 2, to determine the symbol

It may be that there are few F, so I judge F first, and throw the rest to T.

12>11 # 46.7 ns T
12<11 # 46.8 ns F
12<=11 # 46.8 ns F
12>=11 # 47 ns	T
12!=11 # 47 ns T	
12==11 # 47.6 ns F

At least or it can only be certain, right ==
I will deal with it at the end. Although it is almost meaningless, I am sure that I need to develop the habit of not using == as much as possible.

Guess you like

Origin blog.csdn.net/jhsxy2005/article/details/113707053