Re: [xml] i'm here to contribute

[Stefan Sauer <ensonic hora-obscura de>]

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