PR summary

Consider this a proposal-by-draft-PR since I couldn't see how tractable a solution would be until I actually fixed/improved the behavior, and this very well might not be a good solution or work fully correctly yet! #6664 being closed got me to look again at whether in MNE-Python we should plot traces ourselves with fake mini-axes or try creating hundreds of axes (below I used 720 axes):

import numpy as np
import matplotlib.pyplot as plt
import time

rng = np.random.default_rng(0)
n_ch = 720
n_samp = 1000
n_col = int(np.ceil(np.sqrt(n_ch)))
n_row = int(np.ceil(n_ch / n_col))
t = np.linspace(0, 1. / n_col * 0.8, n_samp)
data = rng.uniform(0, 1. / n_row * 0.8, (n_ch, n_samp))
positions = np.array(
    np.meshgrid(
        np.linspace(0, 1, n_row + 2)[1:-1],
        np.linspace(0, 1, n_col + 2)[1:-1],
    )
)
positions.shape = (2, -1)
positions = positions.T[:n_ch]
assert positions.shape == (n_ch, 2)

rcParams = plt.rcParams
rcParams['xtick.top'] = False
rcParams['xtick.bottom'] = False
rcParams['xtick.labeltop'] = False
rcParams['xtick.labelbottom'] = False
rcParams['ytick.left']  = False
rcParams['ytick.right'] = False
rcParams['ytick.labelleft'] = False
rcParams['ytick.labelright'] = False
rcParams["axes.grid"] = False

# Unified
t0 = time.time()
fig = plt.figure(layout=None)
ax = fig.add_axes([0, 0, 1, 1])
for p, d in zip(positions, data):
    ax.plot(p[0] + t, p[1] + d, color='k', lw=0.5)
fig.canvas.draw_idle()
print(time.time() - t0)

t0 = time.time()
fig, axes = plt.subplots(n_row, n_col, layout=None)
for ax, d in zip(axes.ravel(), data):
    ax.plot(t, d, color="k", lw=0.5)
    ax.axis("off")
for ax in axes.ravel()[n_ch:]:
    fig.delaxes(ax)
fig.canvas.draw_idle()
print(time.time() - t0)

Running this script on main, the first time is the time it takes to plot all 720 of the 1000-sample traces within a single Axes (positioning them with offsets) versus using 720 axes, each with a single trace:

0.28928518295288086
2.8085598945617676

On this PR the timings are:

0.3005490303039551
0.9130969047546387

So we cut the time down from ~2.8s to ~0.9s. The code here was developed using kernprof/line-profiler to see that the bulk of time was spent formatting ticks that would never be used. To prevent tick creation (and thus reformatting) both of the changes in this PR were necessary, namely:

1. autodetecting when NullLocator can be used in LinearScale, and
2. explicitly avoiding creating any ticks when NullLocator is in use
3. avoid accessing majorTicks[0] without checking len first in one place (could be others!)

It really doesn't seem like (2) should be required in principle, but I couldn't figure out how to avoid the tick creation with the _LazyTickList and how it gets accessed/used -- I couldn't wrap my head around it, and no matter what I did, 2 ticks were always created per axis. And that means 4 per plot, i.e., 2880 ticks with text and lines and such that need to be processed (hence the time savings by avoiding it in this PR).

If this seems like a reasonable or workable approach, it looked like there was some very similar code elsewhere in scale.py that could use a similar treatment.

Profiling with py-spy record -f speedscope --subprocesses --nonblocking --rate 1000 python ~/Desktop/topo_bench.py I'm not sure there are any more big gains to be made here, maybe another 50 ms from avoiding spines or 50 ms from avoiding text resetting but those seem like much more challenging targets:

cc @drammock and @ruuskas who I discussed this with a bit recently

PR checklist

• [N/A] "closes #0000" is in the body of the PR description to link the related issue

• [N/A] new and changed code is tested

  • Existing tests should pass and I'm not sure we could query the problematic, intermediate/transient (I think) internal state where .majorTicks has two entries even when NullLocator is in use.

• [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