Did anyone discover what caused the slight slowdown in the initial PR's benchmark?

Did anyone discover what caused the slight slowdown in the initial PR's benchmark?

Maybe the additional tests for consuming references?
I don't think it matters much, as specialization will handle all the fast paths.

🤖 New build scheduled with the buildbot fleet by @markshannon for commit 7c0f498 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

A little bit faster

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 03e7ad9 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

I ran the buildbots earlier. All good except the Gentoo ones failing for tkinter stuff.
Feel free to re-run them, in case I broke something in the last couple of commits.

Unfortunately, seems that this commit has broken the AMD64 FreeBSD Shared 3.x buildbot:

https://buildbot.python.org/all/#/builders/483/builds/1003/steps/5/logs/stdio

The buildbot was green until we merged this

The BSD entry in https://devguide.python.org/experts/ is empty. Not only that, but the gdb tests are decidedly uninformative when they fail. I'll see what I can come up with.

I am taking a look as well, seems that the problem is that it cannot find builtin_id:

Function "builtin_id" not defined.

This is one of the errors:

AssertionError:


'Breakpoint 1 (builtin_id) pending.
Breakpoint 1, builtin_id (self=<optimized out>, v=42) at Python/bltinmodule.c:1197
1197        PyObject *id = PyLong_FromVoidPtr(v);
#4 Frame 0x800235020, for file ...gdb_sample.py, line 12, in <module> ()
    foo(1, 2, 3)
Unable to find an older python frame
Locals for <module>

did not match

'^.*\nLocals for foo\na = 1\nb = 2\nc = 3\nLocals for <module>\n.*$'

So seems that it was not able to find the previous python frame for some reason

Something is going on, I logged into the buildbot (you need to ask koobs for access by writting to koobs@freebsd.org) and indeed many commands are broken:

140-CURRENT-amd64-564d% gdb --args ./python Lib/test/gdb_sample.py
(gdb) b builtin_id
(gdb) r
Breakpoint 1, builtin_id (self=<optimized out>, v=0x801424c00) at Python/bltinmodule.c:1197
...
(gdb) py-list
   7        baz(a, b, c)
   8
   9    def baz(*args):
  10        id(42)
  11
 >12    foo(1, 2, 3)

while on my Linux system:

❯ gdb --args ./python Lib/test/gdb_sample.py
(gdb) b builtin_id
(gdb) r
Breakpoint 1, builtin_id (self=0x7ffff7928470, v=42) at Python/bltinmodule.c:1196
1196    {
(gdb) py-list
   5
   6    def bar(a, b, c):
   7        baz(a, b, c)
   8
   9    def baz(*args):
 >10        id(42)
  11
  12    foo(1, 2, 3)
(gdb)

@markshannon I know the problem. The problem is this code:

This is not correct anymore when the frames are inlined as that frame is the top frame of all of them. The problem is that in the buildbot, the frame is optimized so it goes into this fallback.

I will try to prepare a PR for this.