./python.exe -m pyperf timeit "a = 3.5" "b = a // 2"
AS-IS: Mean +- std dev: 377 ns +- 4 ns
my patch: Mean +- std dev: 204 ns +- 2 ns

Is this worth optimising? Floating-point floor division is a comparatively rare operation.

> Is this worth optimizing? Floating-point floor division is a comparatively rare operation.

1. I don't want to say that this should always be optimized.
2. However, this operation is a relatively primitive python operation. I think this optimization is easy to bring and worth it.
3. Besides, the relatively unchanged logic, so the maintenance cost is not expected to be large

And on the other side,

>>> 3.8 // 0.0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: float divmod()

I think that people expect 
ZeroDivisionError: float floor division by zero

not the current message.
I caught this optimization issue during I investigate about the error message.

So the risk here is that by adding the floordiv fast path, the division code is duplicated, and that increases the risk of accidentally losing the invariant that `a // b` is interchangeable with `divmod(a, b)[0]` (e.g., because someone decides to "fix" the floor float division). That and the usual increased maintenance cost of more code.

Whether the optimization is worth the cost, I'm not sure. My gut feeling is not, but others may have different views.

> (e.g., because someone decides to "fix" the floor float division)

Okay, what if we create a common divmod function except for creating a tuple?

@mark.dickinson

I extract the common function.
Now maintainence cost is same as AS-IS.

optimization is still work :)

AS-IS: Mean +- std dev: 360 ns +- 19 ns
TO-BE: Mean +- std dev: 185 ns +- 8 ns

what do you think?

New changeset 8d49f7ceb4f961770ae61fe6a4033c4e61cc3288 by Dong-hee Na in branch 'master':
bpo-39434: Improve float __floordiv__ performance and error message (GH-18147)
https://github.com/python/cpython/commit/8d49f7ceb4f961770ae61fe6a4033c4e61cc3288

Thank you!

Thanks, that's a nice optimization!

I'm surprised that creating a tuple of 2 items, get one item  directly into the C structure, and destroy the tuple is so slow (360 ns => 185 ns: 175 ns less). With my FASTCALL optimization on function calls, I recall that avoiding the creation a tuple of N items made function calls around 20 ns faster. Not 175 ns.

Victor: I suspect there's some compiler magic going on, too; a good compiler should be able to figure out that half of the div/mod calculation is not being used, and strip it out. That wouldn't have been possible before with the tuple packing and unpacking.

Small style question: using 5 spaces in https://github.com/python/cpython/blob/master/Objects/floatobject.c#L655-L664 after PR 18147 merged.
Due to bpo don't receive style quesiton, I commented here.

@shihai1991 Good catch! Now fixed.

Thanks good catch :)