Conceptually using a list for adding keyword arguments would be faster than adding tuples together (because the former can sometimes extend in-place depending on when resizes are triggered). Note, there is already a C fast path so this code doesn't normally get used in CPython. This edit is confined to the kwds section so as to not impair the common case of having no keyword arguments.

Also, use a list comprehension rather than a generator expression in the typed section. Historically, PyPy doesn't optimize genexps as much as list comps. In CPython, genexps have become slower than list comps because the latter are inlined in more recent versions. Note the typed section is rarely used.

Suggested by @heikkitoivonen

This PR is likely to have almost no real world effect but I think it is conceptually nicer and will do better in extreme cases with many keyword arguments.

Side note: in the past I've looked at using map in the typed section but that had a negative effect in PyPy and was of negligible impact on CPython.

Also note that when I previous benchmarked various approaches in CPython, the measurements were not consistent across versions (3.x vs 3.x+1) or builds (Windows/Mac/Linux). We really don't want to chase the interpreter into local minimums that don't payoff for everyone or that change over time. That applies even more to the current situation where the interpreter is being changed almost daily (due to structural optimizations, opcode changes, JIT work, free-threading work, etc).

Generally, we value code stability more than micro-optimizations but I think this one is worth reexamining because the context has changed. When the code was first built, the run time was dominated by sorting and the HashedSeq wrapper. First sorting was eliminated, then recently HashedSeq was removed when tuples learned to cache their hash values. The code that remained was much faster than before. So now, these kinds of micro-edits have proportionally more potential value.

• Issue: functools._make_key is slow due to creation of lots of temporary tuples - optimizable with list #143825