Re: [xml] i'm here to contribute

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:

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?

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]