Re: MacPorts xsltproc is very slow?

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> Does anyone know why I'd see this difference in "make docs" performance?

> 1. On macOS using Apple's /usr/bin/xsltproc (--version says libxml
> 20902, libxslt 10128 and libexslt 817), it builds in a few minutes but
> produces warnings like this:

> postgres.sgml:408: element biblioentry: validity error : ID ston89b
> already defined
> postgres.sgml:426: element biblioentry: validity error : ID ston90a
> already defined
> postgres.sgml:454: element biblioentry: validity error : ID ston90b
> already defined

FWIW, I see no such warnings using the system xsltproc on either Sierra
or High Sierra. Both of them show

$ xsltproc --version
Using libxml 20904, libxslt 10129 and libexslt 817
xsltproc was compiled against libxml 20904, libxslt 10129 and libexslt 817
libxslt 10129 was compiled against libxml 20904
libexslt 817 was compiled against libxml 20904

and build the HTML docs in about a minute and a half.

> I noticed that the Apple version is using libxslt 1.1.28 (for context,
> that's the same as Debian Jessie used; Stretch/Buster/Sid are on
> 1.1.29 -- I'm guessing many of you are using that?), whereas MacPorts
> is shipping libxslt 1.1.32. I know next to nothing about these tools
> but I wonder if something we're doing gets horribly slow in future
> libxslt versions that will come down the pipeline on other
> distributions. Or if the MacPorts port is just borked somehow.

This seems vaguely reminiscent of this recent discussion:

https://www.postgresql.org/message-id/flat/8F33D0C7-E12E-4996-990C-3CF0C5ED0437%40filmlance.se

in which the conclusion seemed to be that Apple's build of zlib was
considerably faster than another build (of uncertain provenance, mind you,
so maybe that is unrelated). I wonder whether Apple are using more
aggressive optimization flags than other people. OTOH, while it would
not surprise me if Apple put some work into making zlib go fast, it
seems less likely that they'd expend effort or risk on xsltproc.

regards, tom lane