[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Re: Support for callout extensions in xsltproc
On Thu, Aug 07, 2003 at 10:36:24AM -0400, Jeff Beal wrote: > I'll go ahead and file that. If you need a large test-doc, I'll figure thanks > something out. Our doc is proprietary, so I can't just send it to you > as-is, but I can run it through an XSLT transform to obfuscate the text. no, don't worry but indicate all the parameter and level of the stylesheets used please. > > > I should also point out that my doc set is abnormally huge. > > On my dual PIII > > > 1.4 GHz machine, either processor takes almost five hours > > to do a complete > > > build. We build 26 manuals simultaneously, which are about > > 10,000 printed > > > pages and about 6,000 HTML files. There may just be something about > > > scalability where Saxon wins out. > > > > Yes in that case the Java load + warmup of the JIT is lost in the > > time spent on processing. But for a 5hours processing my take is that > > you're likely to swap like hell on the box, measuring purely the speed > > of your I/O subsystem. I doubt the CPU load it 100% of the CPU (or > > 2x50% depending on the scheduling and affinity processing of your OS > > since you're wunning an SMP). 5 hours of a 1.4 GHZ CPU is way too much > > IMHO even for 6000 resulting files. I bet it's totally I/O bound, the > > swap processing competing with the write I/O of the chunking code. > > It doesn't seem to be doing any processor scheduling with either xsltproc or > saxon, but either of them will get full usage of a single processor for the > duration of the build. When I do two builds at once -- one for HTML Help, > one for Oracle Help (JavaHelp variant) -- I get full usage out of both > processors. okay, surprizing :-) That mean I don't need a very large test to do the profiling, profiling on a "normal sized" document but with chunking enabled should be sufficient. I don't think I ever tried to really profile the HTML serialization too my main path is XML in/XML out maybe there is something going on there. I assume you serialize to HTML, not XHTML, right ? > > Definitely not "common usage" ... :-) > > Absolutely not. That's why I hadn't bothered complaining about performance > in the past. (I'm still not complaining. I build overnight. It gives my > computer something to do while I'm gone.) yeah, but still ... if I there is a problem I can pinpoint, everybody may benefit from it and some people use libxslt for on-the-fly transformation on GUI. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]