Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 5DF9F9F9EED
	for <pgsql-docs-postgresql.org@postgresql.org>;
	Sat,  9 Dec 2006 14:32:43 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024)
	with ESMTP id 43226-08 for <pgsql-docs-postgresql.org@postgresql.org>;
	Sat,  9 Dec 2006 14:32:42 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id BC8909F9392
	for <pgsql-docs@postgresql.org>; Sat,  9 Dec 2006 14:32:42 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kB9IWfp6019233
	for <pgsql-docs@postgresql.org>; Sat, 9 Dec 2006 13:32:41 -0500 (EST)
To: pgsql-docs@postgresql.org
Subject: Re: Switching to XML 
In-reply-to: <1165655250.2621.10.camel@josh> 
References: <4579720E.4000707@dawninglight.net>
	<200612082115.53566.peter_e@gmx.net>
	<1165609294.24745.19.camel@localhost.localdomain>
	<200612082158.06649.peter_e@gmx.net>
	<1165613160.24745.36.camel@localhost.localdomain>
	<1165655250.2621.10.camel@josh>
Comments: In-reply-to Theo Kramer <theo@flame.co.za>
	message dated "Sat, 09 Dec 2006 11:07:30 +0200"
Date: Sat, 09 Dec 2006 13:32:41 -0500
Message-ID: <19232.1165689161@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200612/57
X-Sequence-Number: 3980

>> The french team also uses Docbook XML and they can generate a PDF in 30
>> minutes... it takes us DAYS because of the SGML.

Has anyone looked into actually fixing the performance problem?

oprofile results for jade trying to produce tex output from our docs are
suggestive of a localized performance issue:

samples  %        symbol name
2082917  98.5829  OpenJade_DSSSL::PairNodeListObj::nodeListFirst(OpenJade_DSSSL::EvalContext&, OpenJade_DSSSL::Interpreter&)
9713      0.4597  OpenJade_DSSSL::PairNodeListObj::nodeListRest(OpenJade_DSSSL::EvalContext&, OpenJade_DSSSL::Interpreter&)
5019      0.2375  OpenJade_DSSSL::AppendSosofoObj::traceSubObjects(Collector&) const
3571      0.1690  Collector::collect()
1938      0.0917  OpenJade_DSSSL::FlowObj::traceSubObjects(Collector&) const

I attached to the process with gdb and found it nested four thousand (!)
call levels deep in OpenJade_DSSSL::PairNodeListObj::nodeListFirst and
OpenJade_DSSSL::PairNodeListObj::nodeListRest calls.  Meanwhile, looking
at the output-so-far-emitted makes me think it was working on a fairly
large <programlisting> example.  The last little bit is:

{asis}\def\InputWhitespaceTreatment%
{preserve}}\Seq%
{}\Seq%
{}~~~~\endSeq{}/*
\Seq%
{}~~~~\endSeq{}~*~testlibpq2.c
\Seq%
{}~~~~\endSeq{}~*~~~~~~Test~of~the~asynchronous~notification~interface
\Seq%
{}~~~~\endSeq{}~*
\Seq%
{}~~~~\endSeq{}~*~Start~this~program,~then~from~psql~in~another~window~do
\Seq%
{}~~~~\endSeq{}~*~~~NOTIFY~TBL2;
\Seq%
{}~~~~\endSeq{}~*~Repeat~four~times~to~get~this~program~to~exit.
\Seq%
{}~~~~\endSeq{}~*
\Seq%
{}~~~~\endSeq{}~*~Or,~if~you~want~to~get~fancy,~try~this:
\Seq%
{}~~~~\endSeq{}~*~populate~a~database~with~th

What it looks like to me is that there is some bit of stupidity that is
producing a deeply nested list representation of a <programlisting>
section, probably one list level per character in the text, making the
runtime O(N^2) or worse in the length of the <programlisting>.  (The
particular example it's stuck on here is about 10K characters.)

Since jade does not go into this kind of spiral when producing html
output from the same sources, I suggest that it's not jade's fault,
but rather crummy coding in the sgml-to-tex conversion scripts it's
using.  I don't know enough about those to know where to look, but maybe
someone here does?

			regards, tom lane