Skip to content
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

Remove has_equations from the mathematics domain #13044

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

AA-Turner
Copy link
Member

Feature or Bugfix

  • Performance

Purpose

When profiling, MathDomain.process_doc() takes around 1% of runtime. We can reduce this to ~0.

Copy link
Member

@picnixz picnixz left a comment

Choose a reason for hiding this comment

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

I think we need a CHANGELOG entry to indicate that a new context data has been added to the context object for the handler and that a publicly named (yet probably not documented) method has been removed from the domain API.

I have a very bad Internet connection so I don't know if I'll be able to review more.

sphinx/writers/html.py Outdated Show resolved Hide resolved
sphinx/writers/html5.py Outdated Show resolved Hide resolved
@chrisjsewell
Copy link
Member

Heya, you do realise this is used by one of sphinx's own extensions 😅: https://github.com/sphinx-doc/sphinxcontrib-jsmath/blob/19763d7fc9ebb29eb2f325fef0bc6f067907a233/sphinxcontrib/jsmath/__init__.py#L70
it is also used here: https://github.com/jbms/sphinx-immaterial/blob/69e685aedd338f6766ddb5bae9b2189d2e7a6898/sphinx_immaterial/local_mathjax.py#L28

Calling a method internal, just because it is undocumented, is incorrect; if does not start with an _ it is public.

Not saying not to change, but the new means of detection should also be public and documented

@AA-Turner
Copy link
Member Author

Calling a method internal, just because it is undocumented, is incorrect; if does not start with an _ it is public.

Whilst we are now using this philosophy for new code, I don't think it holds true for old code, where marking names as private was less deliberate.

Both cases you cite are effective copies of ext.mathjax, but I will see if there is a means to improve compatability (at the very least, restore MathDomain.has_equations() and always return True).

A

@picnixz
Copy link
Member

picnixz commented Oct 24, 2024

I think we should restore has_equations(). On the other hand, I'm wondering whether has_equations could be cached or if there was a reason why I didn't consider it at that time. For instance:

return (
    self.data['has_equations'].get(docname, False)
    or any(map(self.has_equations, self.env.toctree_includes.get(docname, ())))
)

works well the first time, but I'm wondering if we shouldn't just do

has_equations = self.data['has_equations'].get(docname, False)
if has_equations:
	return True

has_equations = any(map(self.has_equations, self.env.toctree_includes.get(docname, ())))
if has_equations:
	self.data['has_equations'][docname] = True
return has_equations

This could at least save re-testing has_equations. We can also save some memory by only keeping the docnames that have equations in a set instead of a dict.

@AA-Turner
Copy link
Member Author

The slow bit isn't has_equations, but process_doc - iterating through every node of every document takes a long time.

@chrisjsewell
Copy link
Member

I don't think it holds true for old code, where marking names as private was less deliberate.

I really think it does; users will not care about your standards, if something is not _ they have every right to use it and probably have (a bug s a feature lol)
... but I don't want to block on this; I don't think has_equations is that important a hill to die on 😄

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.

3 participants