Re: [xslt] likely/unlikely hinting for libxml/libxslt
- From: Daniel Veillard <veillard redhat com>
- To: The Gnome XSLT library mailing-list <xslt gnome org>
- Cc: Stefan Behnel <stefan_ml behnel de>
- Subject: Re: [xslt] likely/unlikely hinting for libxml/libxslt
- Date: Thu, 18 Mar 2010 11:54:38 +0100
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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]