Skip to content

Conversation

@scottshambaugh
Copy link
Contributor

PR summary

Towards #5665

This shortcuts major or minor ticks processing when they are set to not visible, or their locators are NullLocators. In theory, NullLocators just return an empty list, but in practice its parent class does a fair amount of work during initialization that we don't need.

Here's a representative profiling run for _update_ticks(). The circled bit is skipped with this PR, roughly 20% of the function call time.
image

PR checklist

Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this improves speed ok.

But overall it's quite weird that it does and to me it's an indicator that we have some fundamental issues with ticks.

What exactly does the trick? _tick_group_visible or the NullLocator? I would have expected that NullLocator (i.e. major_locs == []) should not incur notable costs. format_ticks(()); get_major_ticks(0), loop over a 0-length zip should all be no cost.

By default the major ticks are on and the minor ticks of. Do you get the speed just from the minor tick branch?

Anyway a substantial cost will remain for the cases that do have ticks. Updating all ticks individually trough a loop and ticks consisting of multiple artists, that in turn have to be updated is vastly inefficient. I want to explicitly bring #5665 (comment) to attention again as a long term strategy to clean up all the tick mess.


Side note: Doc build errors are entries from https://github.com/matplotlib/matplotlib/blob/main/doc/missing-references.json.
Either the PR does change some line numbers (which regular invalidate the exceptions listed in missing-references.json), or it's something in the wake of sphinx 9.1, which has substantially reworked autodoc and known to cause issues in several docs.

@scottshambaugh
Copy link
Contributor Author

All the speed up in my profiling reference case comes from the minor ticks NullLocator path, from not having to initialize the NullLocator object. Probably indicates some work that could be lazified, but I agree that efforts would be better spent with an overhaul.

@timhoffm
Copy link
Member

Quite interesting. NullLocator() and its parents do not even have an __init__, so it's likely the fact that we are setting up a locator or the resulting update machinery (which we're in here).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants