Wow, thanks! That explains it.

The problem is rather that the way the perfs are measured is biased ("like usual"...?)

Considering the inputs used, the VERY GREAT MAJORITY of the outputs are -1. That means that what is measured is actually:

• v1:
  • call + arithmetic
  • compare
  • return
• v2:
  • call
  • store
  • load + arithmetic
  • compare
  • return

So, yeah, v2 is ofc a tiny bit slower.

Now, if you try with a perfect square as input for each call, the result will be the opposite:

1st variant: 2.9085514545440674
2nd variant: 2.345383644104004

Wow, this brings me back :-)

Checked the code, the difference is still present, and the first option is faster.

I'm not sure why exactly, checked the opcodes using dis.dis, and figured that the only difference is that

LOAD_GLOBAL              0 (sqrt)
LOAD_FAST                0 (sq)
CALL_FUNCTION            1

is called for the first one, and

STORE_FAST               1 (s)
LOAD_FAST                1 (s)
LOAD_FAST                1 (s)

for the second function (same opcodes omitted).

So it looks like storing a value is more expensive then calling a function.

I know that this is old, but why is it slower? Does the assignment really add more time than recalculating the sqrt?