Re: Large SGML Cleanup

Excerpts from Alvaro Herrera's message of jue nov 04 14:51:10 -0300 2010:
> Excerpts from Peter Eisentraut's message of mié nov 03 12:35:34 -0300 2010:
>
> > Here is some data to entertain along the way:
> >
> > make html  107.85s user 0.57s system 92% cpu 1:56.65 total
> >
> > make xslthtml  13.98s user 1331.22s system 98% cpu 22:46.46 total
>
> Ugh, that's horrible :-(

This seems like a bug in xsltproc.  A bit of strace shows that it's
full of this stuff:

stat("/usr/lib/libxslt-plugins/nwalsh_com_xslt_ext_com_nwalsh_saxon_UnwrapLinks.so", 0x7fff86f35f40) = -1 ENOENT (No
suchfile or directory) 
stat("/usr/lib/libxslt-plugins/nwalsh_com_xslt_ext_com_nwalsh_saxon_UnwrapLinks.so", 0x7fff86f357c0) = -1 ENOENT (No
suchfile or directory) 
stat("/usr/lib/libxslt-plugins/nwalsh_com_xslt_ext_com_nwalsh_saxon_UnwrapLinks.so", 0x7fff86f35f40) = -1 ENOENT (No
suchfile or directory) 

I didn't let it finish to verify that it's really the time sink, though.
But note that user time is a lot lower than with the SGML toolchain;
it's system time that's the problem (which is suspicious in itself).

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support