public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Thomas Munro <[email protected]>
Cc: [email protected]
Subject: Re: MacPorts xsltproc is very slow?
Date: Fri, 24 Nov 2017 23:28:46 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEepm=2HZ+LkTSMtihu61wd63vpLwYE-cE41syf=1FHsO6gybg@mail.gmail.com>
References: <CAEepm=2HZ+LkTSMtihu61wd63vpLwYE-cE41syf=1FHsO6gybg@mail.gmail.com>

Thomas Munro <[email protected]> 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

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]
  Subject: Re: MacPorts xsltproc is very slow?
  In-Reply-To: <[email protected]>

* 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