Re: [xslt] likely/unlikely hinting for libxml/libxslt

[Daniel Veillard <veillard redhat com>]

On Sat, Mar 06, 2010 at 03:25:16PM +0200, Stefan Kost wrote:
> Am 15.02.2010 10:47, schrieb Stefan Behnel:
> > 
> > Stefan Kost, 10.02.2010 09:43:
> >> in the quest of figuring our what canb be done to make gtk-doc less slow
> >> (where the only slow part is the docbook xslt processing) I was running
> >> it under oprofile and studying the report. Below is the profile
> >> (probably nothing new in there). Attached is also the callgraph as an
> >> image (not sure if that will get through to the list).
> > 
> > Note that KCacheGrind claims to have support for oprofile. Should make such
> > a graph a lot more accessible.
> > 
> > 
> >> Some questions:
> >>
> >> * I'd suggest to make use of __builtin_expect() in libxml. glib does:
> >>
> >> #if defined(__GNUC__) && (__GNUC__ > 2) && defined(__OPTIMIZE__)
> >> #define G_LIKELY(expr) (__builtin_expect ((expr), 1))
> >> #define G_UNLIKELY(expr) (__builtin_expect ((expr), 0))
> >> #else
> >> #define G_LIKELY(expr) (expr)
> >> #define G_UNLIKELY(expr) (expr)
> >> #endif
> > 
> > We actually do this in Cython:
> > 
> > #ifdef __GNUC__
> > /* Test for GCC > 2.95 */
> > #if __GNUC__ > 2 || \
> >               (__GNUC__ == 2 && (__GNUC_MINOR__ > 95))
> > #define likely(x)   __builtin_expect(!!(x), 1)
> > #define unlikely(x) __builtin_expect(!!(x), 0)
> > #else /* __GNUC__ > 2 ... */
> > #define likely(x)   (x)
> > #define unlikely(x) (x)
> > #endif /* __GNUC__ > 2 ... */
> > #else /* __GNUC__ */
> > #define likely(x)   (x)
> > #define unlikely(x) (x)
> > #endif /* __GNUC__ */
> > 
> > 
> >> Could that be added to libxml as e.g. XML_{UN,}LIKELY?
> > 
> > +1
> > 
> >> It could be used e.g. in xpathInternals.h, e.g. for
> >>
> >> #define CHECK_ERROR                            \
> >>     if (XML_UNLIKELY (ctxt->error != XPATH_EXPRESSION_OK)) return
> >>
> >> With the attached (hackish patch) I got the % for xmlXPathCompOpEval
> >> from 22.69% down to 17.70%.
> >> (this was just on, but one long iteration).
> > 
> > Sounds like a case to me.
> > 
> > 
> >> If there is no one against such an approach I can make a proper patch
> >> and submit it to bugzilla.
> > 
> > Please do. I can't guarantee that it will go in, but once it's there, I
> > can't really see a reason why it shouldn't.
> 
> Sorry, I missed the reply. I have the patch now, but I must have had a
> meassurement error paired with sudden euphoria of being able to to speed things
> up. I havn't got a convincing speedup since. I'll need to run more tests and
> exclude external interference.

  So what's the outcome ? It sounds like a cheap and rather safe
modification, but if it doesn't help speed wise well ...

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/