From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Claudio Fontana <cfontana@suse.de>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: sphinx-build is really slow, any way to improve that?
Date: Tue, 06 Sep 2022 10:17:27 +0200 [thread overview]
Message-ID: <87h71k533c.fsf@pond.sub.org> (raw)
In-Reply-To: <CAFEAcA_ed-ny6eodA=9fK6Y5WpUaRO0jPfbKHYCB6uLikiyiHQ@mail.gmail.com> (Peter Maydell's message of "Mon, 5 Sep 2022 22:21:55 +0100")
Peter Maydell <peter.maydell@linaro.org> writes:
> On Mon, 5 Sept 2022 at 20:51, Claudio Fontana <cfontana@suse.de> wrote:
>> when I build qemu, there is a lot of time spent at the end of the build where one cpu goes 100% on sphinx-build.
>>
>> Is there some way to parallelize that? It seems it is the current bottleneck for rebuilds for me..
>
> It's a big fat python program, so I suspect not, but
> maybe I'm wrong.
>
> You can always configure --disable-docs if you don't care
> about the docs and want to make builds faster.
I care about the docs, but the impact on turnaround time is so bad I
stopped building the docs in the build trees I use for development, and
instead keep a separate tree that has docs enabled. Tends to delay
diagnosis of doc markup errors, but that's the lesser evil for me.
We used to have a similar problem with generated C: touch the QAPI
schema, rebuild everything and its dog. That was because everything and
its dog depended on the generated QAPI header. C projects 101: putting
everything in a single header slows down rebuilds.
We solved this by splitting up the generated header, and updating
generated headers only when they actually change.
I have no idea whether Sphinx could do a similarly incremental rebuild.
prev parent reply other threads:[~2022-09-06 8:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 19:48 sphinx-build is really slow, any way to improve that? Claudio Fontana
2022-09-05 21:21 ` Peter Maydell
2022-09-06 7:55 ` Daniel P. Berrangé
2022-09-06 13:41 ` Peter Maydell
2022-09-06 13:57 ` Daniel P. Berrangé
2022-09-07 8:59 ` Markus Armbruster
2022-09-06 8:17 ` Markus Armbruster [this message]
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=87h71k533c.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=cfontana@suse.de \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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.