...as discussed in https://github.com/faster-cpython/ideas/discussions/263.

My plan is for this initial PR to lay the groundwork, then to work on porting over the existing opcode caches one-by-one. Once that's done, we can clean up lots of the "old" machinery.

We need to decide what to do about dis.

I don't think we should have a `show_cache` option, as the caches are meaningless junk without quickening (maybe we should drop the CACHE opcode, and just use zeroes).

Instead we should have a `show_quickened` option, to show the quickened form, which we need to make clear is very much implementation defined.
E.g. Cinder might show the machine code as well.

That way, we can present the cache information as extra data on the quickened form, rather than junk instructions.

New changeset 0f41aac109c45aa468c432f798947c54d4178b3d by Brandt Bucher in branch 'main':
bpo-46841: Use *inline* caching for `BINARY_OP` (GH-31543)
https://github.com/python/cpython/commit/0f41aac109c45aa468c432f798947c54d4178b3d

Making this a release blocker, as we really cannot leave this half finished for the release.

Shouldn't be a problem, as we'll have it done in a week or so.

New changeset 424ecab494d538650ba34937cdd710094ccb2275 by Brandt Bucher in branch 'main':
bpo-46841: Use inline caching for `UNPACK_SEQUENCE` (GH-31591)
https://github.com/python/cpython/commit/424ecab494d538650ba34937cdd710094ccb2275

New changeset 4558af5a8f8e56a9b0dc11f6e834c47e0fd05f9e by Mark Shannon in branch 'main':
bpo-46841: Move the cache for `LOAD_GLOBAL` inline. (GH-31575)
https://github.com/python/cpython/commit/4558af5a8f8e56a9b0dc11f6e834c47e0fd05f9e

New changeset 7820a5897e7762df23bff1cbe749652130654a08 by Brandt Bucher in branch 'main':
bpo-46841: Use inline caching for `COMPARE_OP` (GH-31622)
https://github.com/python/cpython/commit/7820a5897e7762df23bff1cbe749652130654a08

New changeset 3b0f1c5a710eff289dc44bec972dbaea353cc54f by Mark Shannon in branch 'main':
bpo-46841: Use inline cache for `BINARY_SUBSCR`. (GH-31618)
https://github.com/python/cpython/commit/3b0f1c5a710eff289dc44bec972dbaea353cc54f

UNPACK_SEQUENCE's slowdown is already filed?

https://speed.python.org/timeline/#/?exe=12&ben=unpack_sequence&env=4&revs=50&equid=off&quarts=on&extr=on

I hit the gap at 424ecab on Windows.

This is marked as a release blocker so I am holding the alpha release on this. Is there anything we can do to unblock this issue?

Is there some way to mark something as not blocking an alpha release, but blocking a beta release?

Everything is working at the moment, but not so efficiently.

We should be done with this by early next week, if you can wait.

> Is there some way to mark something as not blocking an alpha release, but blocking a beta release?

"Deferred blocker"

Good to know, although "deferred blocker" is somewhat vague about when it is deferred until.

OOI, does it become a "blocker" again once you've done the alpha release, or what stops it being deferred past the beta or even the final release?

It's not an UNPACK_SEQUENCE slowdown, it's a silly benchmark ;)

https://github.com/python/pyperformance/blob/main/pyperformance/data-files/benchmarks/bm_unpack_sequence/run_benchmark.py#L6

What I *think* is happening is that the inline cache takes the size of the function (in code units) from about 4800 to about 5200, crossing our threshold for quickening (currently set to 5000).

When we quicken in-place, there will be no need for a threshold and this issue will disappear. We should probably up the threshold for now, just to keep the charts looking good.

> OOI, does it become a "blocker" again once you've done the alpha release, or what stops it being deferred past the beta or even the final release?

Check out the devguide:

https://devguide.python.org/triaging/#priority

> The issue will not hold up the next release, n. It will be promoted to a release blocker for the following release, n+1.

But in any case, I normally promote them to release blockers by hand and all of them become full blockers in the beta.

> What I *think* is happening is that the inline cache takes the size of the function (in code units) from about 4800 to about 5200, crossing our threshold for quickening (currently set to 5000).

Yep, nailed it:

>>> len(list(dis.get_instructions(do_unpacking)))
4827
>>> len(list(dis.get_instructions(do_unpacking, show_caches=True)))
5251
>>> do_unpacking(1_000, range(10))
0.06478393300494645
>>> do_unpacking.__code__._co_quickened is None
True

New changeset 127797f572cc7374192e415c44ea2e95b009d5ab by Brandt Bucher in branch 'main':
bpo-46841: Improve the failure stats for COMPARE_OP (GH-31663)
https://github.com/python/cpython/commit/127797f572cc7374192e415c44ea2e95b009d5ab

New changeset 05a8bc1c944709e7468f157bd1b6032f368e43bf by Brandt Bucher in branch 'main':
bpo-46841: Use inline caching for attribute accesses (GH-31640)
https://github.com/python/cpython/commit/05a8bc1c944709e7468f157bd1b6032f368e43bf

New changeset 586b24d3be1aec5d2568b070a249b4d75e608782 by Brandt Bucher in branch 'main':
bpo-46841: Fix error message hacks in `GET_AWAITABLE` (GH-31664)
https://github.com/python/cpython/commit/586b24d3be1aec5d2568b070a249b4d75e608782

New changeset c4d2d57eefb1224a12e2e95e4508658dfbf6a7c9 by Brandt Bucher in branch 'main':
bpo-46841: Fix BINARY_OP's handling of inline caches (GH-31671)
https://github.com/python/cpython/commit/c4d2d57eefb1224a12e2e95e4508658dfbf6a7c9

New changeset f193631387bfee99a812e39b05d5b7e6384b57f5 by Brandt Bucher in branch 'main':
bpo-46841: Use inline caching for calls (GH-31709)
https://github.com/python/cpython/commit/f193631387bfee99a812e39b05d5b7e6384b57f5

New changeset 5498a61c7c25db6f9e76032aa9c5153d79e09889 by Brandt Bucher in branch 'main':
bpo-46841: Don't use an oparg counter for `STORE_SUBSCR` (GH-31742)
https://github.com/python/cpython/commit/5498a61c7c25db6f9e76032aa9c5153d79e09889

New changeset a89c29fbcc7e7e85848499443d819c3fab68c78a by Brandt Bucher in branch 'main':
bpo-46841: Add a _Py_SET_OPCODE macro (GH-31780)
https://github.com/python/cpython/commit/a89c29fbcc7e7e85848499443d819c3fab68c78a

New changeset 49e1e1e1bd59cac1855b1ef4dec05d649ebcd81a by Mark Shannon in branch 'main':
bpo-46841: Don't scan backwards in bytecode (GH-31901)
https://github.com/python/cpython/commit/49e1e1e1bd59cac1855b1ef4dec05d649ebcd81a

New changeset 2bde6827ea4f136297b2d882480b981ff26262b6 by Brandt Bucher in branch 'main':
bpo-46841: Quicken code in-place (GH-31888)
https://github.com/python/cpython/commit/2bde6827ea4f136297b2d882480b981ff26262b6

New changeset 2f49b97cc5426087b46515254b9a97a22ee8c807 by Irit Katriel in branch 'main':
bpo-46841: remove no-longer-used macro UPDATE_PREV_INSTR_OPARG (GH-32100)
https://github.com/python/cpython/commit/2f49b97cc5426087b46515254b9a97a22ee8c807

New changeset bd2e47c8830d1b2869f2b4345945a5e0c3b4e3fb by Brandt Bucher in branch 'main':
bpo-46841: Avoid unnecessary allocations in code object comparisons (GH-32222)
https://github.com/python/cpython/commit/bd2e47c8830d1b2869f2b4345945a5e0c3b4e3fb

New changeset ae9de82e321581e1906c6ef2a7ad83ab30ae3325 by Brandt Bucher in branch 'main':
bpo-46841: Use a `bytes` object for `_co_code_adaptive` (GH-32205)
https://github.com/python/cpython/commit/ae9de82e321581e1906c6ef2a7ad83ab30ae3325