Sphinx 6.0 removed the execfile_() function, which we use as part of the
configuration process. They *did* warn us... Just open-code the
functionality as is done in Sphinx itself.
Tested (using SPHINX_CONF, since this code is only executed with an
alternative config file) on various Sphinx versions from 2.5 through 6.0.
Reported-by: Martin Liška <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
---
Documentation/sphinx/load_config.py | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/sphinx/load_config.py b/Documentation/sphinx/load_config.py
index eeb394b39e2c..8b416bfd75ac 100644
--- a/Documentation/sphinx/load_config.py
+++ b/Documentation/sphinx/load_config.py
@@ -3,7 +3,7 @@
import os
import sys
-from sphinx.util.pycompat import execfile_
+from sphinx.util.osutil import fs_encoding
# ------------------------------------------------------------------------------
def loadConfig(namespace):
@@ -48,7 +48,9 @@ def loadConfig(namespace):
sys.stdout.write("load additional sphinx-config: %s\n" % config_file)
config = namespace.copy()
config['__file__'] = config_file
- execfile_(config_file, config)
+ with open(config_file, 'rb') as f:
+ code = compile(f.read(), fs_encoding, 'exec')
+ exec(code, config)
del config['__file__']
namespace.update(config)
else:
--
2.38.1
On Wed, 04 Jan 2023 13:45:35 -0700, Jonathan Corbet wrote:
> Sphinx 6.0 removed the execfile_() function, which we use as part of the
> configuration process. They *did* warn us... Just open-code the
> functionality as is done in Sphinx itself.
>
> Tested (using SPHINX_CONF, since this code is only executed with an
> alternative config file) on various Sphinx versions from 2.5 through 6.0.
>
> Reported-by: Martin Liška <[email protected]>
> Signed-off-by: Jonathan Corbet <[email protected]>
I have tested full builds of documentation with this change
with Sphinx versions 1.7.9, 2.4.5, 3.4.3, 4.5.0, 5.3.0, and 6.0.0.
Tested-by: Akira Yokosawa <[email protected]>
That said, Sphinx 6.0.0 needs much more time and memory than earlier
versions.
FYI, I needed to limit parallel slot to 2 (make -j2) on a 16GB machine.
If you are lucky, -j3 and -j4 might succeed. -j5 or more ended up in
OOM situations for me:
Comparison of elapsed time and maxresident with -j2:
============== ============ ===========
Sphinx version elapsed time maxresident
============== ============ ===========
5.3.0 10:16.81 937660
6.0.0 17:29.07 5292392
============== ============ ===========
Thanks, Akira
> ---
> Documentation/sphinx/load_config.py | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/sphinx/load_config.py b/Documentation/sphinx/load_config.py
> index eeb394b39e2c..8b416bfd75ac 100644
> --- a/Documentation/sphinx/load_config.py
> +++ b/Documentation/sphinx/load_config.py
> @@ -3,7 +3,7 @@
>
> import os
> import sys
> -from sphinx.util.pycompat import execfile_
> +from sphinx.util.osutil import fs_encoding
>
> # ------------------------------------------------------------------------------
> def loadConfig(namespace):
> @@ -48,7 +48,9 @@ def loadConfig(namespace):
> sys.stdout.write("load additional sphinx-config: %s\n" % config_file)
> config = namespace.copy()
> config['__file__'] = config_file
> - execfile_(config_file, config)
> + with open(config_file, 'rb') as f:
> + code = compile(f.read(), fs_encoding, 'exec')
> + exec(code, config)
> del config['__file__']
> namespace.update(config)
> else:
> --
> 2.38.1
Em Sat, 7 Jan 2023 14:17:24 +0900
Akira Yokosawa <[email protected]> escreveu:
> On Wed, 04 Jan 2023 13:45:35 -0700, Jonathan Corbet wrote:
> > Sphinx 6.0 removed the execfile_() function, which we use as part of the
> > configuration process. They *did* warn us... Just open-code the
> > functionality as is done in Sphinx itself.
> >
> > Tested (using SPHINX_CONF, since this code is only executed with an
> > alternative config file) on various Sphinx versions from 2.5 through 6.0.
> >
> > Reported-by: Martin Liška <[email protected]>
> > Signed-off-by: Jonathan Corbet <[email protected]>
>
> I have tested full builds of documentation with this change
> with Sphinx versions 1.7.9, 2.4.5, 3.4.3, 4.5.0, 5.3.0, and 6.0.0.
>
> Tested-by: Akira Yokosawa <[email protected]>
>
> That said, Sphinx 6.0.0 needs much more time and memory than earlier
> versions.
>
> FYI, I needed to limit parallel slot to 2 (make -j2) on a 16GB machine.
> If you are lucky, -j3 and -j4 might succeed. -j5 or more ended up in
> OOM situations for me:
>
> Comparison of elapsed time and maxresident with -j2:
>
> ============== ============ ===========
> Sphinx version elapsed time maxresident
> ============== ============ ===========
> 5.3.0 10:16.81 937660
> 6.0.0 17:29.07 5292392
> ============== ============ ===========
From the changelogs:
https://www.sphinx-doc.org/en/master/changes.html
It seems that 6.1 came with some performance optimizations, in particular:
Cache doctrees in the build environment during the writing phase.
Make all writing phase tasks support parallel execution.
Cache doctrees between the reading and writing phases.
It would be nice if you could also test and check elapsed time
there too, as I suspect that 6.0 will have a very short usage, as
6.1 was released just a few days after it.
Regards,
Mauro.
>
> Thanks, Akira
>
> > ---
> > Documentation/sphinx/load_config.py | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/sphinx/load_config.py b/Documentation/sphinx/load_config.py
> > index eeb394b39e2c..8b416bfd75ac 100644
> > --- a/Documentation/sphinx/load_config.py
> > +++ b/Documentation/sphinx/load_config.py
> > @@ -3,7 +3,7 @@
> >
> > import os
> > import sys
> > -from sphinx.util.pycompat import execfile_
> > +from sphinx.util.osutil import fs_encoding
> >
> > # ------------------------------------------------------------------------------
> > def loadConfig(namespace):
> > @@ -48,7 +48,9 @@ def loadConfig(namespace):
> > sys.stdout.write("load additional sphinx-config: %s\n" % config_file)
> > config = namespace.copy()
> > config['__file__'] = config_file
> > - execfile_(config_file, config)
> > + with open(config_file, 'rb') as f:
> > + code = compile(f.read(), fs_encoding, 'exec')
> > + exec(code, config)
> > del config['__file__']
> > namespace.update(config)
> > else:
> > --
> > 2.38.1
Thanks,
Mauro
On 1/8/23 15:01, Mauro Carvalho Chehab wrote:
> Em Sat, 7 Jan 2023 14:17:24 +0900
> Akira Yokosawa <[email protected]> escreveu:
>
>> On Wed, 04 Jan 2023 13:45:35 -0700, Jonathan Corbet wrote:
>>> Sphinx 6.0 removed the execfile_() function, which we use as part of the
>>> configuration process. They *did* warn us... Just open-code the
>>> functionality as is done in Sphinx itself.
>>>
>>> Tested (using SPHINX_CONF, since this code is only executed with an
>>> alternative config file) on various Sphinx versions from 2.5 through 6.0.
>>>
>>> Reported-by: Martin Liška <[email protected]>
>>> Signed-off-by: Jonathan Corbet <[email protected]>
>>
>> I have tested full builds of documentation with this change
>> with Sphinx versions 1.7.9, 2.4.5, 3.4.3, 4.5.0, 5.3.0, and 6.0.0.
>>
>> Tested-by: Akira Yokosawa <[email protected]>
>>
>> That said, Sphinx 6.0.0 needs much more time and memory than earlier
>> versions.
>>
>> FYI, I needed to limit parallel slot to 2 (make -j2) on a 16GB machine.
>> If you are lucky, -j3 and -j4 might succeed. -j5 or more ended up in
>> OOM situations for me:
>>
>> Comparison of elapsed time and maxresident with -j2:
>>
>> ============== ============ ===========
>> Sphinx version elapsed time maxresident
>> ============== ============ ===========
>> 5.3.0 10:16.81 937660
>> 6.0.0 17:29.07 5292392
>> ============== ============ ===========
Hi.
I can confirm the regression, I bisected Sphinx revision that caused that
and filled an upstream issues:
https://github.com/sphinx-doc/sphinx/issues/11116
Cheers,
Martin
>
> From the changelogs:
> https://www.sphinx-doc.org/en/master/changes.html
>
> It seems that 6.1 came with some performance optimizations, in particular:
>
> Cache doctrees in the build environment during the writing phase.
>
> Make all writing phase tasks support parallel execution.
>
> Cache doctrees between the reading and writing phases.
>
> It would be nice if you could also test and check elapsed time
> there too, as I suspect that 6.0 will have a very short usage, as
> 6.1 was released just a few days after it.
>
> Regards,
> Mauro.
>
>
>
>>
>> Thanks, Akira
>>
>>> ---
>>> Documentation/sphinx/load_config.py | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/sphinx/load_config.py b/Documentation/sphinx/load_config.py
>>> index eeb394b39e2c..8b416bfd75ac 100644
>>> --- a/Documentation/sphinx/load_config.py
>>> +++ b/Documentation/sphinx/load_config.py
>>> @@ -3,7 +3,7 @@
>>>
>>> import os
>>> import sys
>>> -from sphinx.util.pycompat import execfile_
>>> +from sphinx.util.osutil import fs_encoding
>>>
>>> # ------------------------------------------------------------------------------
>>> def loadConfig(namespace):
>>> @@ -48,7 +48,9 @@ def loadConfig(namespace):
>>> sys.stdout.write("load additional sphinx-config: %s\n" % config_file)
>>> config = namespace.copy()
>>> config['__file__'] = config_file
>>> - execfile_(config_file, config)
>>> + with open(config_file, 'rb') as f:
>>> + code = compile(f.read(), fs_encoding, 'exec')
>>> + exec(code, config)
>>> del config['__file__']
>>> namespace.update(config)
>>> else:
>>> --
>>> 2.38.1
>
>
>
> Thanks,
> Mauro
On Mon, 9 Jan 2023 15:14:46 +0100, Martin Liška wrote:
> On 1/8/23 15:01, Mauro Carvalho Chehab wrote:
>> Em Sat, 7 Jan 2023 14:17:24 +0900
>> Akira Yokosawa <[email protected]> escreveu:
>>
>>> On Wed, 04 Jan 2023 13:45:35 -0700, Jonathan Corbet wrote:
>>>> Sphinx 6.0 removed the execfile_() function, which we use as part of the
>>>> configuration process. They *did* warn us... Just open-code the
>>>> functionality as is done in Sphinx itself.
>>>>
>>>> Tested (using SPHINX_CONF, since this code is only executed with an
>>>> alternative config file) on various Sphinx versions from 2.5 through 6.0.
>>>>
>>>> Reported-by: Martin Liška <[email protected]>
>>>> Signed-off-by: Jonathan Corbet <[email protected]>
>>>
>>> I have tested full builds of documentation with this change
>>> with Sphinx versions 1.7.9, 2.4.5, 3.4.3, 4.5.0, 5.3.0, and 6.0.0.
>>>
>>> Tested-by: Akira Yokosawa <[email protected]>
>>>
>>> That said, Sphinx 6.0.0 needs much more time and memory than earlier
>>> versions.
>>>
>>> FYI, I needed to limit parallel slot to 2 (make -j2) on a 16GB machine.
>>> If you are lucky, -j3 and -j4 might succeed. -j5 or more ended up in
>>> OOM situations for me:
>>>
>>> Comparison of elapsed time and maxresident with -j2:
>>>
>>> ============== ============ ===========
>>> Sphinx version elapsed time maxresident
>>> ============== ============ ===========
>>> 5.3.0 10:16.81 937660
>>> 6.0.0 17:29.07 5292392
>>> ============== ============ ===========
>
> Hi.
>
> I can confirm the regression, I bisected Sphinx revision that caused that
> and filled an upstream issues:
> https://github.com/sphinx-doc/sphinx/issues/11116
Thank you Martin for looking into this!
>
> Cheers,
> Martin
>
>>
>> From the changelogs:
>> https://www.sphinx-doc.org/en/master/changes.html
>>
>> It seems that 6.1 came with some performance optimizations, in particular:
>>
>> Cache doctrees in the build environment during the writing phase.
>>
>> Make all writing phase tasks support parallel execution.
>>
>> Cache doctrees between the reading and writing phases.
>>
>> It would be nice if you could also test and check elapsed time
>> there too, as I suspect that 6.0 will have a very short usage, as
>> 6.1 was released just a few days after it.
Here is a table comparing 5.3.0, 6.0.1 and 6.1.2 taken on the same
machine (with 16GiB mem + 2GiB swap):
====== ===================================
elapsed time
-----------------------------------
Sphinx -j1 -j2 -j4 -j6
====== ======== ======== ======== ========
6.1.2 15:11.74 18:06.89 16:39.93 OOM
6.0.1 15:28.19 17:22.15 16:31.30 OOM
5.3.0 14:13.04 10:16.81 8:22.37 8:09.74
====== ======== ======== ======== ========
Note:
- The -j1 run needs an explicit option given to sphinx-build by:
make SPHINXOPTS="-q -j1" htmldocs
- Once an OOM happens, -j4 runs are likely end up in OOM.
Looks like the non-parallel run is the cheapest option for mitigating
the regression.
Thanks, Akira
>>
>> Regards,
>> Mauro.
>>
>>
>>
>>>
>>> Thanks, Akira
On Tue, 10 Jan 2023 00:17:11 +0900, Akira Yokosawa wrote:
> On Mon, 9 Jan 2023 15:14:46 +0100, Martin Liška wrote:
>> Hi.
>>
>> I can confirm the regression, I bisected Sphinx revision that caused that
>> and filled an upstream issues:
>> https://github.com/sphinx-doc/sphinx/issues/11116
>
> Thank you Martin for looking into this!
Thanks to Martin's inputs on the github issue, Sphinx 6.1.3 has released
and the issue is resolved for parallel builds.
However, for non-parallel builds, the memory hog still remains.
Again, this is a table comparing 5.3.0, 6.1.2, and 6.1.3.
====== =================================== ===============================
elapsed time maxresident
----------------------------------- -------------------------------
Sphinx -j1 -j2 -j4 -j6 -j1 -j2 -j4 -j6
====== ======== ======== ======== ======== ======= ======= ======= =======
6.1.3 15:03.83 11:31.99 9:35.15 8:49.01 2949056 1059516 978232 967400
6.1.2 15:11.74 18:06.89 16:39.93 OOM 2961524 5548344 5255372 --
5.3.0 14:13.04 10:16.81 8:22.37 8:09.74 711532 937660 846016 800340
====== =================================== ===============================
Note:
- The -j1 run needs an explicit option given to sphinx-build:
make SPHINXOPTS="-q -j1" htmldocs
I naively assumed that the memory hog would be resolved all together,
but that's not the case.
Martin, could you report the remaining issue to upstream Sphinx?
Thanks, Akira
On 1/12/23 00:13, Akira Yokosawa wrote:
> On Tue, 10 Jan 2023 00:17:11 +0900, Akira Yokosawa wrote:
>> On Mon, 9 Jan 2023 15:14:46 +0100, Martin Liška wrote:
>>> Hi.
>>>
>>> I can confirm the regression, I bisected Sphinx revision that caused that
>>> and filled an upstream issues:
>>> https://github.com/sphinx-doc/sphinx/issues/11116
>>
>> Thank you Martin for looking into this!
>
> Thanks to Martin's inputs on the github issue, Sphinx 6.1.3 has released
> and the issue is resolved for parallel builds.
You're welcome.
>
> However, for non-parallel builds, the memory hog still remains.
> Again, this is a table comparing 5.3.0, 6.1.2, and 6.1.3.
>
> ====== =================================== ===============================
> elapsed time maxresident
> ----------------------------------- -------------------------------
> Sphinx -j1 -j2 -j4 -j6 -j1 -j2 -j4 -j6
> ====== ======== ======== ======== ======== ======= ======= ======= =======
> 6.1.3 15:03.83 11:31.99 9:35.15 8:49.01 2949056 1059516 978232 967400
> 6.1.2 15:11.74 18:06.89 16:39.93 OOM 2961524 5548344 5255372 --
> 5.3.0 14:13.04 10:16.81 8:22.37 8:09.74 711532 937660 846016 800340
> ====== =================================== ===============================
I thank you for the nice numbers you provided.
>
> Note:
> - The -j1 run needs an explicit option given to sphinx-build:
> make SPHINXOPTS="-q -j1" htmldocs
>
> I naively assumed that the memory hog would be resolved all together,
> but that's not the case.
Yep, I would expect that same.
>
> Martin, could you report the remaining issue to upstream Sphinx?
Sure: https://github.com/sphinx-doc/sphinx/issues/11124
Btw. do you have an Github account I can CC?
Cheers,
Martin
>
> Thanks, Akira
>
>
On Thu, 12 Jan 2023 17:22:42 +0100, Martin Liška wrote:
> On 1/12/23 00:13, Akira Yokosawa wrote:
>> On Tue, 10 Jan 2023 00:17:11 +0900, Akira Yokosawa wrote:
>>> On Mon, 9 Jan 2023 15:14:46 +0100, Martin Liška wrote:
>>>> Hi.
>>>>
>>>> I can confirm the regression, I bisected Sphinx revision that caused that
>>>> and filled an upstream issues:
>>>> https://github.com/sphinx-doc/sphinx/issues/11116
>>>
>>> Thank you Martin for looking into this!
>>
>> Thanks to Martin's inputs on the github issue, Sphinx 6.1.3 has released
>> and the issue is resolved for parallel builds.
>
> You're welcome.
>
>>
>> However, for non-parallel builds, the memory hog still remains.
>> Again, this is a table comparing 5.3.0, 6.1.2, and 6.1.3.
>>
>> ====== =================================== ===============================
>> elapsed time maxresident
>> ----------------------------------- -------------------------------
>> Sphinx -j1 -j2 -j4 -j6 -j1 -j2 -j4 -j6
>> ====== ======== ======== ======== ======== ======= ======= ======= =======
>> 6.1.3 15:03.83 11:31.99 9:35.15 8:49.01 2949056 1059516 978232 967400
>> 6.1.2 15:11.74 18:06.89 16:39.93 OOM 2961524 5548344 5255372 --
>> 5.3.0 14:13.04 10:16.81 8:22.37 8:09.74 711532 937660 846016 800340
>> ====== =================================== ===============================
>
> I thank you for the nice numbers you provided.
You are welcome.
>
>>
>> Note:
>> - The -j1 run needs an explicit option given to sphinx-build:
>> make SPHINXOPTS="-q -j1" htmldocs
>>
>> I naively assumed that the memory hog would be resolved all together,
>> but that's not the case.
>
> Yep, I would expect that same.
>
>>
>> Martin, could you report the remaining issue to upstream Sphinx?
>
> Sure: https://github.com/sphinx-doc/sphinx/issues/11124
Thanks!
>
> Btw. do you have an Github account I can CC?
I have reacted with an emoji and subscribed to the issue.
Thanks, Akira
>
> Cheers,
> Martin
>
>>
>> Thanks, Akira
>>
>>
>