Hello Alvaro,
It's caused by the condition
<xsl:when test="function-available('suwl:unwrapLinks')">...
in the simple.xlink template
(docbook/stylesheet/docbook-xsl/xhtml/inline.xsl). (This test executed
for each xlink (~ 90000 times)).
Yes, it's inefficient but it doesn't affect build time (for me).
You can try to apply the attached patch and measure the time with it.
So If the performance is rather acceptable now I'd continue switch to
XML, and get back to the performance issues after the switch.
(epub generation is much more slow, and I have developed a patch to
speed up it too.)
Best regards,
Alexander
01.12.2016 19:49, Alvaro Herrera wrote:
> Pavel Stehule wrote:
>
>> It does much more intensive work with IO - I have feeling like there are
>> intensive fsync.
> You could prove that, by running "make html" under "strace -f -e
> trace=fsync" etc. I just tried that, and I don't see any fsync. I
> guess you could try other syscalls, or simply "-e trace=file". Doing
> the latter I noticed an absolutely stupid number of attempts to open
> file
> /usr/lib/libxslt-plugins/nwalsh_com_xslt_ext_com_nwalsh_saxon_UnwrapLinks.so
> which deserves a WTF.
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers