public inbox for [email protected]
help / color / mirror / Atom feedFrom: Thomas Munro <[email protected]>
To: Tom Lane <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: [email protected]
Subject: Re: MacPorts xsltproc is very slow?
Date: Mon, 27 Nov 2017 11:03:27 +1300
Message-ID: <CAEepm=3soZm9d1w1qsKO6cULdTa3Wmz7ee8_yG72XNKK81Kckg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAEepm=2HZ+LkTSMtihu61wd63vpLwYE-cE41syf=1FHsO6gybg@mail.gmail.com>
<[email protected]>
<CAEepm=082retOdZbr5hbSs19oYyjMkAtM6Ez=KHa5JgG2Wm=sA@mail.gmail.com>
<[email protected]>
<CAEepm=35=a69q8wQk+KMzHtcY_1wd==stCcPjQKxdRGHDOGPdw@mail.gmail.com>
<[email protected]>
On Sun, Nov 26, 2017 at 4:21 AM, Tom Lane <[email protected]> wrote:
> Thomas Munro <[email protected]> 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 <[email protected]> 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
view thread (20+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: MacPorts xsltproc is very slow?
In-Reply-To: <CAEepm=3soZm9d1w1qsKO6cULdTa3Wmz7ee8_yG72XNKK81Kckg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox