On 11/11/2011 03:57 AM, Daniel Veillard wrote: > On Mon, Oct 31, 2011 at 11:48:54PM +0100, Stefan Sauer wrote: >> On 09/18/2011 10:24 PM, Glen Hein wrote: >>> Hello, >>> >>> I'm a software developer and I'd like to contribute to Gnome's XML >>> project. I've used the libxml software for a long time and I'd like to >>> give something back. >>> >>> I just started a voluntary career break, but I'd like to stay active. >>> >>> I looked over the TODO file, but I'm not sure which item to tackle. >>> Could you recommend an item for someone new to the project? >>> >>> Thanks, >>> Glen Hein >>> >> One thing that would be super cool would be multi-threaded xslt >> processing (e.g. for chunked document output). Unfortunately again, this >> is not trivial at all. But any speedup for xslt processing would be >> great. The docbook xml -> html step in gtk-doc is so slow that most >> developers to api-doc generation off still :/ > Processing chunks in a subthread is an interesting idea. The > stylesheet is read-only from a transformation process POV so that > may work without too much crazyness... > Two suggestions: > - what about a reduced simplified DocBook XSLT for gnome, using > only what you care about, that could be packaged and registered > in the XML Catalog, and potentially simplify the processing > running an xsltproc -v on a number of documents and grepping the > results may lead to interesting results (but that will be > voluminous !). I spend a few evenings on trying to make a xsltpp (preprocessor), where I even got stuck at finding api to save a stylesheet back to disk. The idea here was to load a stylesheet, do all the xinlcudes and then do optimisation passes (like substituting parameters, removing unsed templates, branches, ...) and save that as a preprocessed stylesheet. I did some of this manually and it gives some impressive speedups.
> - check where the time is really spent, is that in the XPath engine ? > I used to kcachegrind transformation on DocBook and try to find > what were the hotspot, I think I had that flattened at the time > (6-7 years ago) but with new stylesheets it's possible there > is new troubles, as was pointed out recently. Thats why I wrote the profiler (that I committed in the meantime). On the xslt side using oprofile shows some effects of what is described in the "XPath performance issues" thread and then a lot of cases where each function is fast, but simply called way too often. Stefan > Daniel > _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
