Thomas Munro <thomas.mu...@enterprisedb.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
