Re: [xslt] speeding up xslt in gtk-doc

[Stefan Kost <ensonic hora-obscura de>]

Am 04.05.2011 12:28, schrieb Daniel Veillard:
> On Tue, May 03, 2011 at 06:14:44PM +0300, Stefan Kost wrote:
>> hi,
>>
>> I am still not happy with the time it takes for gtk-doc to generate the
>> html. I did some profiling and tired various changes. Its not too
>> impressive. Just posting them here for feedback and comment on the
>> directions of what would be acceptable or not. I technically have commit
>> rights, so I can push things once they are ready. If patch 0002 looks
>> like a good idea, I can extend it for other accessors.
> 
>   Heretic idea, but what about not using the standard docbook
> stylesheets for this but xsl tuned up to what you actually use and
> need ?

Well, I also use dblatex to create pdfs and docbook-xsl to create man-pages.

> 
>>
>> Test case was generating the html for gstreamer-core api docs
>>
>> real       user       sys
>> ------------------------------ before
>> 1m22.872s  1m17.317s  0m1.444s
>> 1m19.261s  1m17.437s  0m1.384s
>> 1m19.770s  1m17.417s  0m1.264s
>> ------------------------------ 0001-xpath-annotate-branch-prediction.patch
>> 1m18.123s  1m16.677s  0m1.256s
>> 1m18.684s  1m17.181s  0m1.292s
>> 1m18.887s  1m17.217s  0m1.364s
> 
>  Okay this have a bit of an effect at the expense of making the code
> harder to read.

The problem with all the NULL checks in the static function is that probably
lots of them could be asserts instead. asserts can be compiled out and one can
hide the unlikely in the assert macro. Imho for static functions its up to the
caller to pass valid args. In this case also imho the ctxt!=NULL check is
redundant as you check that already.

> 
>> ------------------------------
>> 0002-xpath-split-traversal-into-init-and-next-functions.patch
>> 1m18.537s  1m16.925s  0m1.388s
>> 1m18.616s  1m16.913s  0m1.412s
>> 1m18.249s  1m16.653s  0m1.328s
> 
>   this looks more harmful than anything else, make is more complex,
> increase the number of local variables in a function already big
> all that to avoid a test to NULL which takes no time. NACK

It is not just the check, but it is rather the function call+check the causes
overhead. Let me send the profiles.

> 
>> ------------------------------
>> 0003-xpath-avoid-a-memcpy-on-the-expense-of-temporarily-w.patch
>> 1m17.481s  1m16.137s  0m1.208s
>> 1m17.977s  1m16.481s  0m1.328s
>> 1m17.791s  1m16.413s  0m1.232s
> 
>   why 100 then, try to adjust a bit.
> 

I will improve that one. I have been going over the coverity checks and there is
a bug in the formatNumber function too (which copies the string yet another
time). I'll send a new patch.

> 
>   But really I would not try to chase improvement there. improving the
> compilation of xsltstylesheet is way more likely to return actual gains.
> For example, try to avoid dynamic lookup of variables at runtime,
> most of those can be done at compilation time and this could avoid
> lookups.
> 
>   But before optimizing, where is the time actually spent ?
> My attemps with gprof in the past were kind of use less, I used
> callgrind/kcachegrind like 5-6 years ago to improve speed and
> using this and targetting obvious candidate, did indeed lead to
> improvements.

I have been using oprofile callgraphs. The problem with many of the functions is
not that they are slow, but rather that they call called a million times. Then
even the slightest slowness kicks in (e.g. unneeded checks).

I totally agree that e.g. optimization at compile time might help a lot more,
but those are not very visible. Do you have some pointer for where to start
reading in the code?

Thanks
Stefan

> 
> Daniel
>