From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
Jani Nikula <jani.nikula@intel.com>,
ksummit@lists.linux.dev
Subject: Re: [TECH TOPIC] Kernel documentation
Date: Mon, 20 Nov 2023 15:42:16 +0100 [thread overview]
Message-ID: <20231120154216.683c1203@coco.lan> (raw)
In-Reply-To: <877cmc7cut.fsf@meer.lwn.net>
Em Mon, 20 Nov 2023 06:50:34 -0700
Jonathan Corbet <corbet@lwn.net> escreveu:
> Vegard Nossum <vegard.nossum@oracle.com> writes:
>
> > (We already exchanged on this topic, but repeating it for the list:)
> >
> > On 20/06/2023 21:30, Jonathan Corbet wrote:
> >> Jani Nikula <jani.nikula@intel.com> writes:
> >>
> >>> It should be more feasible to build the documentation. Make it
> >>> faster,
> >
> > When using PyPy instead of CPython to run Sphinx, I see a 22%
> > performance improvement on the kernel documentation, which is not
> > insignificant.
>
> That is nice, but we can't really assume that everybody building the
> docs has pypy around.
>
> >> A while back, I went into Sphinx with a hatchet and managed to take
> >> about 20% off the build time. The C domain stuff builds a data
> >> structure of incredible complexity, then just tosses much of it
> >> away. I've never had the time to figure out why they do that or to
> >> try to get my hack job into a condition where I'd be willing to show
> >> it to my dog, much less the Sphinx developers.
> >
> > I also profiled the documentation build some weeks ago and came to the
> > same conclusion: around 40% of the time is spent inside resolve_xref(),
> > the exact same C domain stuff you mentioned.
> >
> > The gcc project/documentation has the same problem, albeit in the C++
> > domain code, there is an open ticket for it:
> >
> > https://github.com/sphinx-doc/sphinx/issues/10966
> >
> > If we're really not using the functionality provided by the C domain
> > code, maybe instead of ripping it out we could provide something like a
> > conf.py toggle to disable it? (The idea being that the patch would be
> > smaller and more acceptable upstream...)
>
> Ah but we are - it's how we generate all of the cross-references in the
> built docs. My sense, from a couple of years ago though was that parts
> of that code aren't used by *anybody*. But I didn't feel that I'd
> understood it well enough to make a proper patch. I'd really like to
> get back to that.
Cross references is quite useful for media docs. Having a way to
optionally disable it to speedup builds may make some sense, but
the default should be to have it enabled and producing warnings.
There is still a long-term bug on Sphinx C domain logic: it still can't
have symbols with the same name for different types. So, we have a
dozen warnings due to that when building with Sphinx version 3.1 and
above:
https://github.com/sphinx-doc/sphinx/pull/8313
Thanks,
Mauro
next prev parent reply other threads:[~2023-11-20 14:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 17:48 [TECH TOPIC] Kernel documentation Jonathan Corbet
2023-06-20 16:02 ` Jani Nikula
2023-06-20 19:30 ` Jonathan Corbet
2023-11-20 12:06 ` Vegard Nossum
2023-11-20 13:50 ` Jonathan Corbet
2023-11-20 14:42 ` Mauro Carvalho Chehab [this message]
2023-11-20 14:49 ` Johannes Berg
2023-11-20 20:54 ` Jonathan Corbet
2023-06-29 21:34 ` Intersphinx ([TECH TOPIC] Kernel documentation) Jonathan Corbet
2023-06-30 13:17 ` Jani Nikula
2023-06-30 16:54 ` Theodore Ts'o
2023-06-30 17:11 ` Jonathan Corbet
2023-07-02 1:46 ` Steven Rostedt
2023-07-02 4:56 ` Linus Torvalds
2023-07-02 13:18 ` James Bottomley
2023-07-02 18:32 ` Steven Rostedt
2023-07-02 18:44 ` Linus Torvalds
2023-07-03 2:46 ` Theodore Ts'o
2023-06-21 11:04 ` [TECH TOPIC] Kernel documentation Thorsten Leemhuis
2023-06-26 14:34 ` Jan Kara
2023-11-11 12:42 ` Vegard Nossum
2023-11-11 15:14 ` Jonathan Corbet
2023-11-20 12:20 ` Vegard Nossum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231120154216.683c1203@coco.lan \
--to=mchehab@kernel.org \
--cc=corbet@lwn.net \
--cc=jani.nikula@intel.com \
--cc=ksummit@lists.linux.dev \
--cc=vegard.nossum@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.