Re: MacPorts xsltproc is very slow?

On Sun, Nov 26, 2017 at 4:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
>> ... I couldn't help noticing that
>> templates with match="chapter" and match="appendix" appear in our tree
>> in sgml/stylesheet-speedup-common.xsl with a comment
>> "Performance-optimized versions of some upstream templates from
>> common/ directory". Could it be that whatever performance-enhancing
>> trick they perform doesn't work on 1.1.32, or alternatively they are
>> not being reached so we're falling back to non-optimised versions
>> instead of these?
>
> If you're suspicious of that, you could try removing those parts of
> stylesheet-speedup-common.xsl and see what happens ...

Good idea. Removing them didn't help (though removing them makes
Apple xsltproc similarly slow). Adding "d:" namespace to "chapter"
and "appendix", declared in the xsl:stylesheet element as
xmlns:d="http://docbook.org/ns/docbook" didn't help either. I suspect
that could be made to work with some more tweaking, but I lack the XSL
knowledge. I found another way forward though:

On Sun, Nov 26, 2017 at 4:09 AM, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> It seems that your package is built from "ns" version.
> (I couldn't find docbook-xsl-nons in Macports.)
> If it's the only available version for Mac, it seems we need to adjust our
> XSL templates to work with namespaces too.

Aha, you're right! MacPorts does actually have two different ports
(packages): docbook-xsl and docbook-xsl-ns, and the first one should
be the no-namespace variant. But I can clearly see that the
docbook-xsl packages installs stylesheets *with* namespaces. I
compared this with a Debian system and found that common/labels.xsl
(the file that defines the templates that our
stylesheet-speedup-common.xsl seems to want to replace) has the "d:"
prefix on "chapter" and "appendix", but doesn't on the Debian system.
Presumably this interferes with the interposing technique. Perhaps
that is a packaging error that should be reported upstream.

That got me wondering... why does the Apple xsltproc in /usr/bin work
then? Where is it even getting docbook-xsl from? I ran it with
--profile and http://docbook.sourceforge.net instead of file:// URLs,
and I could see outgoing connections with netstat. It believe that's
because it doesn't find it locally in /etc/xml/catalog, whereas the
MacPorts xsltproc looks in /opt/locl/etc/xml/catalog where it has been
listed by the docbook-xsl package.

So one solution is simply to uninstall the docbook-xsl package. That
gets me back to fast documentation builds! Incidentally, uninstalling
the docbooks-xsl package also works for FreeBSD which currently ships
a too-old DocBook version. I believed until now that it couldn't
build the PostgreSQL docs, so I'm very happy to discover that it can,
but (1) it needs the network (2) it's using HTTP instead of HTTPS so
Alice could mess with Bob's documentation.

Thanks both for your help figuring this out. That's quite enough XML
for one day.

--
Thomas Munro
http://www.enterprisedb.com