Codestin Search App

eendebakpt · 2026-04-18T11:30:49Z

PR summary

The performance if matplotlibs ticks is a bottleneck in various plots. See for example the discussions and references in #5665, #31012, #29594.

In this PR we prevent materialization of the _LazyTickList when there are no ticks created yet. With the tick-materialization cascade gone from Axes.__clear, the spine transforms the cascade used to install as a side effect are installed explicitly at the end of __clear.

Benchmark results (updated):

nit_grid 8x8:                  [main] 177 ms ± 2 ms   -> [branch] 112 ms ± 24 ms:  1.58x faster
clear_grid 8x8:                 [main] 181 ms ± 2 ms   -> [branch] 139 ms ± 22 ms:  1.31x faster
reuse_axes 8x8:                 [main] 154 ms ± 1 ms   -> [branch] 53.8 ms ± 0.4 ms: 2.86x faster
fig100 clear+plot1000+legend:   [main] 9.45 ms ± 2.4 ms -> [branch] 3.28 ms ± 0.02 ms: 2.88x faster

Geometric mean: 2.03x faster

Benchmark script

# /// script
# requires-python = ">=3.10"
# dependencies = ['matplotlib', 'numpy', 'pyperf']
# ///
"""pyperf micro-benchmarks for matplotlib axis/tick init+clear cost.

"""
import pyperf

setup = """
import matplotlib
matplotlib.use("Agg")
# matplotlib.use("QtAgg")  # snap/glibc mismatch; use offscreen:
# import os; os.environ.setdefault("QT_QPA_PLATFORM", "offscreen")

import numpy as np
import matplotlib.pyplot as plt

GRID = 8
rng = np.random.default_rng(0)
x1000 = np.arange(1000)
y1000 = rng.standard_normal(1000)

# Pre-create reusable figure for clear_grid / reuse_axes cases.
_fig_clear = plt.figure()
_fig_grid, _axs_grid = plt.subplots(GRID, GRID)
_axs_flat = _axs_grid.ravel()

# Warmup — first call pays font-cache / backend-init costs.
plt.close(plt.subplots(GRID, GRID)[0])
"""

runner = pyperf.Runner()

# Fresh figure each iter — full Axes.__init__ cost for an 8x8 grid.
runner.timeit(
    name="init_grid 8x8",
    stmt="fig, axs = plt.subplots(GRID, GRID); plt.close(fig)",
    setup=setup,
)

# Reuse one Figure, clear + re-populate with an 8x8 grid.
runner.timeit(
    name="clear_grid 8x8",
    stmt="_fig_clear.clear(); _fig_clear.subplots(GRID, GRID)",
    setup=setup,
)

# Iterate ax.clear() across an existing 8x8 grid.
runner.timeit(
    name="reuse_axes 8x8",
    stmt="[ax.clear() for ax in _axs_flat]",
    setup=setup,
)

# Figure num=100: clear + plot 1000-point line + legend. Reuses the same
# numbered figure across iterations so only clear+plot+legend is measured.
runner.timeit(
    name="fig100 clear+plot1000+legend",
    stmt=(
        "fig = plt.figure(num=100);"
        " fig.clear();"
        " ax = fig.add_subplot();"
        " ax.plot(x1000, y1000, label='y');"
        " ax.legend()"
    ),
    setup=setup,
)

Closes #23771.

AI Disclosure

Claude was used in identifying performance bottlenecks related to tick creation. Initially the goal was to create tick collections (as described in one of the references), but this approach seems to be a small change with large impact.

PR checklist

"closes #0000" is in the body of the PR description to link the related issue
new and changed code is tested
[N/A] Plotting related features are demonstrated in an example
[N/A] New Features and API Changes are noted with a directive and release note
[N/A] Documentation complies with general and docstring guidelines

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

timhoffm

Thanks for the PR. The speedup is impressive, and the added complexity (rc caching) is bearable.

Strategically, I would like to move away from single-tick handling, but in the mean time this is a reasonable improvement.

timhoffm · 2026-04-21T13:42:04Z

+        had_major = bool(self.__dict__.pop('majorTicks', None))
+        had_minor = bool(self.__dict__.pop('minorTicks', None))
+        if had_major or had_minor:
+            try:
+                self.set_clip_path(self.axes.patch)
+            except AttributeError:
+                pass


Is this a logical change or just rewriting? AFAICS we can impove the comment to something like

Delete the majorTicks / minorTicks instances so that the _LazyTickList descriptor is reactivated.

This is a logical change as set_clip_path is no longer always executed. I updated the docstring

timhoffm · 2026-04-21T13:52:00Z

+            try:
+                tick = instance._get_tick(major=self._major)
+            finally:
+                rc._update_raw(orig)


Can rc_context be used here?

I suggest to still define a private _rc_context_raw() context manager to simplify the code. The rcParams handling is very much distracting from the non-trivial tick handling code.

eendebakpt · 2026-04-21T20:20:01Z

Strategically, I would like to move away from single-tick handling, but in the mean time this is a reasonable improvement.

Having tick collections is indeed the way to go. This change is orthogonal as it avoids some tick operations altogether. (but maybe if ticks are really fast that would not matter)

timhoffm · 2026-04-21T21:21:16Z

        # Initialize here for testing; later add API
        self._major_tick_kw = dict()
        self._minor_tick_kw = dict()
+        # Snapshot of rcParams at the time of the last ``Axis.clear`` (or


Optional, but comments are never rendered, so ReST formatting is a bit of overkill here. Alternatives:

No quotes but parentheses

[...] time of the last Axis.clear() (or

Single ticks as used in CPython error messages

[...] time of the last 'Axis.clear'

timhoffm · 2026-04-21T21:38:05Z

@@ -550,24 +550,48 @@ def __init__(self, major):
    def __get__(self, instance, owner):
        if instance is None:


Since the logic complexity grows, we should afford a description.

Suggested change

if instance is None:

"""Materialize the desciptor to a list containing one properly configured tick."""

if instance is None:

timhoffm · 2026-04-21T21:56:39Z

+        # may call reset_ticks(). Therefore, the final tick list is
+        # created and assigned afterwards.
+        attr = 'majorTicks' if self._major else 'minorTicks'
+        setattr(instance, attr, [])


Can we keep one named instance around in the function?

create an empty list

assign it to the instance

create and configure the tick

add the tick to the list

return the list

tick_list = [] setattr(instance, attr, tick_list) # must be defined before instance._get_tick() # create and configure the tick tick_list.append(tick) return tick_list

IMHO this is logically clearer than an empty placeholder list that get's replaced later and going back and forward through the instance using multiple getattr/setattr` (which are needed to have one execution path for majorTicks/minorTicks, which in turn is needed because the logical complexity of tick configuring rises and we don't want to duplicate that in two branches for major/minor

timhoffm · 2026-04-21T22:01:42Z

+        Copy Axis clip state onto a lazily-created Tick.
+
+        `Axis.set_clip_path` runs during ``Axes.__clear`` before any Tick
+        exists under the lazy-init refactor, so the clip stored on the


"lazy-init refactor" is a development activity/artifact, not an architectual concept. Also, I'm not exactly sure what "lazy-init refactor" is. Is it the introduction of _LazyTickList or this PR? Please rephrase.

timhoffm · 2026-04-21T22:15:06Z

        return [self.label, self.offsetText,
                *self.get_major_ticks(), *self.get_minor_ticks()]

+    def _propagate_axis_state_to_tick(self, tick):


This could be moved to a method tick._configure_for_axis(axis). Conceptually the tick should know how it needs to be configured; e.g. the Axis should not have to know that the tick itself and its gridline need to be clipped.

timhoffm · 2026-04-21T22:23:10Z

+            try:
+                tick = instance._get_tick(major=self._major)
+            finally:
+                rc._update_raw(orig)


I suggest to still define a private _rc_context_raw() context manager to simplify the code. The rcParams handling is very much distracting from the non-trivial tick handling code.

QuLogic · 2026-04-21T22:26:53Z

+        for spine in self.spines.values():
+            if spine._position is None and spine._transform is self.transData:
+                spine._position = ('outward', 0.0)
+                spine.set_transform(spine.get_spine_transform())


If we're accessing private information like this, is there a reason we don't just call _ensure_position_is_set like in the comment?

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Defer tick materialization during Axes init/clear

d0bb8ff

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

github-actions Bot added topic: ticks axis labels topic: axes labels Apr 18, 2026

eendebakpt marked this pull request as draft April 18, 2026 12:04

fix

3ac8224

eendebakpt force-pushed the perf/lazy-axis-init branch from 5708dc8 to 3ac8224 Compare April 18, 2026 12:21

fix

ceef40c

eendebakpt marked this pull request as ready for review April 18, 2026 16:06

timhoffm reviewed Apr 21, 2026

View reviewed changes

review comments

fe563e3

timhoffm reviewed Apr 21, 2026

View reviewed changes

QuLogic reviewed Apr 21, 2026

View reviewed changes

eendebakpt and others added 3 commits April 23, 2026 21:36

review comments: docstrings, comment style, spine helper

1b72b8b

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

extract _rc_context_raw; simplify _LazyTickList.__get__

e80c08e

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

move clip-state propagation onto Tick._configure_for_axis

d0ed04c

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

eendebakpt force-pushed the perf/lazy-axis-init branch from a3f1be1 to d0ed04c Compare April 23, 2026 19:38

		@@ -550,24 +550,48 @@ def __init__(self, major):
		def __get__(self, instance, owner):
		if instance is None:

	if instance is None:
	"""Materialize the desciptor to a list containing one properly configured tick."""
	if instance is None:

Uh oh!

Conversation

eendebakpt commented Apr 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR summary

AI Disclosure

PR checklist

Uh oh!

timhoffm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eendebakpt commented Apr 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timhoffm Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

eendebakpt commented Apr 18, 2026 •

edited

Loading

timhoffm Apr 21, 2026 •

edited

Loading