[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: More performance issues with XSL 1.52.2
On Fri, Jul 26, 2002 at 02:29:35PM +0200, Kraa de Simon wrote: > Hello, > > Please advise. > > Currently I have one large book (about 5000 html files) and just don't have > enough time to generate the whole document every night. > > Do I understand correctly that splitting the book up into a set of books > won't help me out here because I still have to generate the whole set in one > go? That's correct, if you are trying to cross reference among the books using <xref> and <link>. Those elements use the ID/IDREF mechanism to resolve links, and the ID and IDREF must be in the same document. > Because some of the chapters (books) are quite static / don't change often I > would like to skip those. > > Do I understand correctly that using olink you can accomplish this? > > For example: > > book > chapter 1 - dynamic -> process > chapter 2 - dynamic -> process > chapter 3 - static -> skip > chapter 4 - dynamic -> process > > or > > set > book1 -> process > chapter 1 - dynamic -> process > chapter 2 - dynamic -> process > chapter 3 - static -> skip > chapter 4 - dynamic -> process > book2 -> process > chapter 1 - dynamic -> process > chapter 2 - dynamic -> process > book3 -> skip > chapter 1 > chapter 2 Currently the olink in the XSL stylesheets can't quite do what you want. The scenario where it works best looks like this: book1 -> process book2 -> process book3 -> skip This is a collection of books not inside of a set element, and where you want to form links between the books. By using olink for those links between books, you can avoid having to create one huge set document just to form links. With this scenario, you can process a single book whenever something changes in that book. But you have to be careful, because when you start using olinks, you create dependencies between your books. Let's say you change a chapter title in book1 and reprocess that book. If your book3 has an olink to that chapter, and that olink element contains no text, then the chapter title link text that was generated the last time book3 was processed is now wrong and needs to be updated. If you use Makefiles, you can have book3 be dependent on book1's target data file, which is generated for olinking. If you are careful to not alter the timestamp on the target data file unless it actually changes, then the dependency works. See http://www.sagehill.net/xml/docbookxsl/Olinking.html (the section on Using Makefiles) for an example. You can also split a book up into chapter files, and use olinks to link among the book's chapter files. If you use XInclude instead of system entities to assemble the book, then you can have fully valid chapter files. That's a nice feature for writing and editing. But processing a single chapter with the current stylesheets will always yield "Chapter 1" in the output, because that's the 'document' the processor is seeing. There are two ways around that. One way is to put a fixed "label" attribute on each chapter element, but that loses autonumbering. Who wants to manually maintain chapter numbers? Not me. Or you can process your master book file with the 'rootid' parameter to select a single chapter for output. This still loads and parses the entire book though, so I don't think it speeds things up a lot. Since all we need is to set the chapter number, I have in mind a new parameter that tells the stylesheet to get the chapter number from the target data file for the book. But that feature isn't implemented yet. Taking that idea a step further, you could construct a mega table of contents from your target database. It contains all the hierarchy, text, and URL information it needs to do that. So theoretically you could generate something like a complete set TOC for your collection of books, even though you have no set element. Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: bobs@caldera.com > > -----Oorspronkelijk bericht----- > Van: Bob Stayton [mailto:bobs@caldera.com] > Verzonden: woensdag 24 juli 2002 22:57 > Aan: Jeff Beal; DocBook Mailing List (E-mail) > Onderwerp: Re: DOCBOOK-APPS: More performance issues with XSL 1.52.2 > > > On Wed, Jul 24, 2002 at 03:36:17PM -0400, Jeff Beal wrote: > > In a previous post, I noted that my build time increased by a ridiculous > > amount (5 hours to 50, more or less) when upgrading from the 1.48 > > stylesheets to the 1.52.2 stylesheets. With a little bit of customization > > (discussed on those threads) I was able to get my time to something > slightly > > faster than the 1.48 stylesheets. However, that allowed the build to go > > further than I had allowed it to go, revealing grossly huge memory > > utilization. Instead of using around 350MB of RAM, it now maxes out at > > 1.4GB of RAM, and Java can't seem to handle any more than that - it > crashes. > > (I had to play with the -X parameters to get it to go as high as 1.4GB). > > I've tried a couple of different things, including looking for more > > customizations and using different Saxon switches, and the long and short > of > > it all seems to be that I can't use the 1.52.2 stylesheets with Saxon. > I'd > > switch to xsltproc at this point, but I really need the extension > functions > > Norm provides, and one of my own that handles all of my graphics in a > rather > > nice way. > > > > Any ideas here? > > It sounds like you are processing very large documents, > such as sets of books? You might consider processing > smaller modules and using olinks to connect them. > The 1.52 stylesheets have a new olink implementation > that makes olinking easier. I haven't publicized it > yet because 1.52.2 has a little glitch that's fixed > in CVS, but I can help you try it out if you are > interested. > > -- > > Bob Stayton 400 Encinal Street > Publications Architect Santa Cruz, CA 95060 > Technical Publications voice: (831) 427-7796 > Caldera International, Inc. fax: (831) 429-1887 > email: bobs@caldera.com -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: bobs@caldera.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC