From: "Daniel P. Berrangé" <berrange@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, 6 Sep 2022 14:57:37 +0100 [thread overview]
Message-ID: <YxdR0W0rFoBjkYcI@redhat.com> (raw)
In-Reply-To: <CAFEAcA8DZZe2XKntbrg2mOrmWmepPAVvgBKTvO9vMAE2tVq2hg@mail.gmail.com>
On Tue, Sep 06, 2022 at 02:41:13PM +0100, Peter Maydell wrote:
> On Tue, 6 Sept 2022 at 08:55, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Mon, Sep 05, 2022 at 10:21:55PM +0100, Peter Maydell wrote:
> > > 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.
> >
> > It annoys me too and I've had a look at what it is doing in the past and
> > failed to find an obvious way to improve it. I fear this could be an
> > inherant limitation of the way we use sphinx to build the docs as a
> > complete manual, as compared to say treating each docs source file as
> > a distinct standalone web page.
>
> IIRC sphinx really really wants to process the whole document tree
> in one go. You can see this in the way that for example the
> HTML build process creates HTML files for the top-level rst
> files that are supposed to be only for the manpage -- it will
> suck in and process everything, not just the files reachable
> via whatever top level file you point it at.
Yeah, thats why I think we're limited by what sphinx upstream can do
for us. They need to be able to parallelize stuff in their loading
and generation code.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-09-06 15:06 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é [this message]
2022-09-07 8:59 ` Markus Armbruster
2022-09-06 8:17 ` Markus Armbruster
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=YxdR0W0rFoBjkYcI@redhat.com \
--to=berrange@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.