Skip to content

GH-123299: Copyedit 3.14 What's New: Optimizations #137789

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Aug 15, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions Doc/library/pdb.rst
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,7 @@ The debugger's prompt is ``(Pdb)``, which is the indicator that you are in debug
arguments of the ``p`` command.


.. _pdb-cli:
.. program:: pdb

You can also invoke :mod:`pdb` from the command line to debug other scripts. For
Expand Down
186 changes: 105 additions & 81 deletions Doc/whatsnew/3.14.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1288,12 +1288,11 @@ asyncio
:meth:`asyncio.TaskGroup.create_task`.
(Contributed by Thomas Grainger in :gh:`128307`.)


bdb
---

* The :mod:`bdb` module now supports the :mod:`sys.monitoring` backend.
(Contributed by Tian Gao in :gh:`124533`.)
* There are two new utility functions for
introspecting and printing a program's call graph:
:func:`~asyncio.capture_call_graph` and :func:`~asyncio.print_call_graph`.
(Contributed by Yury Selivanov, Pablo Galindo Salgado, and Łukasz Langa
in :gh:`91048`.)


.. _whatsnew314-color-calendar:
Expand Down Expand Up @@ -1521,36 +1520,6 @@ functools
(Contributed by Sayandip Dutta in :gh:`125916`.)


gc
--

The cyclic garbage collector is now incremental,
which changes the meaning of the results of
:meth:`~gc.get_threshold` and :meth:`~gc.set_threshold`
as well as :meth:`~gc.get_count` and :meth:`~gc.get_stats`.

* For backwards compatibility, :meth:`~gc.get_threshold` continues to return
a three-item tuple.
The first value is the threshold for young collections, as before;
the second value determines the rate at which the old collection is scanned
(the default is 10, and higher values mean that the old collection
is scanned more slowly).
The third value is meaningless and is always zero.

* :meth:`~gc.set_threshold` ignores any items after the second.

* :meth:`~gc.get_count` and :meth:`~gc.get_stats` continue to return
the same format of results.
The only difference is that instead of the results referring to
the young, aging and old generations,
the results refer to the young generation
and the aging and collecting spaces of the old generation.

In summary, code that attempted to manipulate the behavior of the cycle GC
may not work exactly as intended, but it is very unlikely to be harmful.
All other code will work just fine.


getopt
------

Expand Down Expand Up @@ -1919,13 +1888,6 @@ pdb
* ``$_asynctask`` is added to access the current asyncio task if applicable.
(Contributed by Tian Gao in :gh:`124367`.)

* :mod:`pdb` now supports two backends: :func:`sys.settrace` and
:mod:`sys.monitoring`. Using :mod:`pdb` CLI or :func:`breakpoint` will
always use the :mod:`sys.monitoring` backend. Explicitly instantiating
:class:`pdb.Pdb` and its derived classes will use the :func:`sys.settrace`
backend by default, which is configurable.
(Contributed by Tian Gao in :gh:`124533`.)

* :func:`pdb.set_trace_async` is added to support debugging asyncio
coroutines. :keyword:`await` statements are supported with this
function.
Expand Down Expand Up @@ -2266,14 +2228,16 @@ zipinfo

.. Add improved modules above alphabetically, not here at the end.
Optimizations
=============

* The import time for several standard library modules has been improved,
including :mod:`ast`, :mod:`asyncio`, :mod:`base64`, :mod:`cmd`, :mod:`csv`,
:mod:`gettext`, :mod:`importlib.util`, :mod:`locale`, :mod:`mimetypes`,
:mod:`optparse`, :mod:`pickle`, :mod:`pprint`, :mod:`pstats`, :mod:`socket`,
:mod:`subprocess`, :mod:`threading`, :mod:`tomllib`, and :mod:`zipfile`.
including :mod:`annotationlib`, :mod:`ast`, :mod:`asyncio`, :mod:`base64`,
:mod:`cmd`, :mod:`csv`, :mod:`gettext`, :mod:`importlib.util`, :mod:`locale`,
:mod:`mimetypes`, :mod:`optparse`, :mod:`pickle`, :mod:`pprint`,
:mod:`pstats`, :mod:`shlex`, :mod:`socket`, :mod:`string`, :mod:`subprocess`,
:mod:`threading`, :mod:`tomllib`, :mod:`types`, and :mod:`zipfile`.

(Contributed by Adam Turner, Bénédikt Tran, Chris Markiewicz, Eli Schwartz,
Hugo van Kemenade, Jelle Zijlstra, and others in :gh:`118761`.)
Expand All @@ -2282,32 +2246,44 @@ Optimizations
asyncio
-------

* :mod:`asyncio` has a new per-thread double linked list implementation internally for
:class:`native tasks <asyncio.Task>` which speeds up execution by 10-20% on standard
pyperformance benchmarks and reduces memory usage.
* Standard benchmark results have improved by 10-20%, following the
implementation of a new per-thread double linked list
for :class:`native tasks <asyncio.Task>`,
also reducing memory usage.
This enables external introspection tools such as
:ref:`python -m asyncio pstree <whatsnew314-asyncio-introspection>`
to introspect the call graph of asyncio tasks running in all threads.
(Contributed by Kumar Aditya in :gh:`107803`.)

* :mod:`asyncio` has first class support for :term:`free-threading builds <free threading>`.
This enables parallel execution of multiple event loops across different threads and scales
linearly with the number of threads.
* The module now has first class support for
:term:`free-threading builds <free threading>`.
This enables parallel execution of multiple event loops across
different threads, scaling linearly with the number of threads.
(Contributed by Kumar Aditya in :gh:`128002`.)

* :mod:`asyncio` has new utility functions for introspecting and printing
the program's call graph: :func:`asyncio.capture_call_graph` and
:func:`asyncio.print_call_graph`.
(Contributed by Yury Selivanov, Pablo Galindo Salgado, and Łukasz Langa
in :gh:`91048`.)


base64
------

* Improve the performance of :func:`base64.b16decode` by up to ten times,
and reduce the import time of :mod:`base64` by up to six times.
(Contributed by Bénédikt Tran, Chris Markiewicz, and Adam Turner in :gh:`118761`.)
* :func:`~base64.b16decode` is now up to six times faster.
(Contributed by Bénédikt Tran, Chris Markiewicz, and Adam Turner
in :gh:`118761`.)


bdb
---

* The basic debugger now has a :mod:`sys.monitoring`-based backend,
which can be selected via the passing ``'monitoring'``
to the :class:`~bdb.Bdb` class's new *backend* parameter.
(Contributed by Tian Gao in :gh:`124533`.)


difflib
-------

* The :func:`~difflib.IS_LINE_JUNK` function is now up to twice as fast.
(Contributed by Adam Turner and Semyon Moroz in :gh:`130167`.)


gc
Expand All @@ -2316,42 +2292,90 @@ gc
* The new :ref:`incremental garbage collector <whatsnew314-incremental-gc>`
means that maximum pause times are reduced
by an order of magnitude or more for larger heaps.

Because of this optimization, the meaning of the results of
:meth:`~gc.get_threshold` and :meth:`~gc.set_threshold` have changed,
along with :meth:`~gc.get_count` and :meth:`~gc.get_stats`.

- For backwards compatibility, :meth:`~gc.get_threshold` continues to return
a three-item tuple.
The first value is the threshold for young collections, as before;
the second value determines the rate at which the old collection is scanned
(the default is 10, and higher values mean that the old collection
is scanned more slowly).
The third value is now meaningless and is always zero.

- :meth:`~gc.set_threshold` now ignores any items after the second.

- :meth:`~gc.get_count` and :meth:`~gc.get_stats` continue to return
the same format of results.
The only difference is that instead of the results referring to
the young, aging and old generations,
the results refer to the young generation
and the aging and collecting spaces of the old generation.

In summary, code that attempted to manipulate the behavior of the cycle GC
may not work exactly as intended, but it is very unlikely to be harmful.
All other code will work just fine.

(Contributed by Mark Shannon in :gh:`108362`.)


io
---
* :mod:`io` which provides the built-in :func:`open` makes less system calls
when opening regular files as well as reading whole files. Reading a small
operating system cached file in full is up to 15% faster.
:func:`pathlib.Path.read_bytes` has the most optimizations for reading a
file's bytes in full. (Contributed by Cody Maloney and Victor Stinner in
:gh:`120754` and :gh:`90102`.)

* Opening and reading files now executes fewer system calls.
Reading a small operating system cached file in full is up to 15% faster.
(Contributed by Cody Maloney and Victor Stinner
in :gh:`120754` and :gh:`90102`.)


pathlib
-------

* :func:`Path.read_bytes <pathlib.Path.read_bytes>` now uses unbuffered mode
to open files, which is between 9% and 17% faster to read in full.
(Contributed by Cody Maloney in :gh:`120754`.)


pdb
---

* :mod:`pdb` now supports two backends, based on either
:func:`sys.settrace` or :mod:`sys.monitoring`.
Using the :ref:`pdb CLI <pdb-cli>` or :func:`breakpoint`
will always use the :mod:`sys.monitoring` backend.
Explicitly instantiating :class:`pdb.Pdb` and its derived classes
will use the :func:`sys.settrace` backend by default, which is configurable.
(Contributed by Tian Gao in :gh:`124533`.)


uuid
----

* Improve generation of :class:`~uuid.UUID` objects via their dedicated
functions:

* :func:`~uuid.uuid3` and :func:`~uuid.uuid5` are both roughly 40% faster
for 16-byte names and 20% faster for 1024-byte names. Performance for
longer names remains unchanged.
* :func:`~uuid.uuid4` is 30% faster.
* :func:`~uuid.uuid3` and :func:`~uuid.uuid5` are now both roughly 40% faster
for 16-byte names and 20% faster for 1024-byte names.
Performance for longer names remains unchanged.
(Contributed by Bénédikt Tran in :gh:`128150`.)

* :func:`~uuid.uuid4` is now c. 30% faster.
(Contributed by Bénédikt Tran in :gh:`128150`.)


zlib
----

* On Windows, ``zlib-ng`` is now used as the implementation of the
:mod:`zlib` module. This should produce compatible and comparable
results with better performance, though it is worth noting that
``zlib.Z_BEST_SPEED`` (1) may result in significantly less
compression than the previous implementation (while also significantly
reducing the time taken to compress).
* On Windows, `zlib-ng <https://github.com/zlib-ng/zlib-ng>`__
is now used as the implementation of the :mod:`zlib` module
in the default binaries.
There are no known incompatabilities between ``zlib-ng``
and the previously-used ``zlib`` implementation.
This should result in better performance at all compression levels.

It is worth noting that ``zlib.Z_BEST_SPEED`` (``1``) may result in
significantly less compression than the previous implementation,
whilst also significantly reducing the time taken to compress.

(Contributed by Steve Dower in :gh:`91349`.)


Expand Down
Loading