[xslt] Bug Fix doubles the XSL preprocessing time

I noticed that the processing time of my large
stylesheets  (i.e., running xsltParseStylesheetDoc)
almost doubled between 1.1.14 and 1.1.15.

I was able to trace the change to the following fix:


I am not very familiar with the actual bug fixed

libxslt/xsltutils.c: fixed a bug when size of
  changes, uses the libxml2 alloc and dealloc
functions instead.

but I can see how adding xmlXPathNewContext for each
xpath compiled can be expensive....

Here is a suggested patch which seems to fix the

--- xsltutils.c.orig    2006-04-08 14:44:33.000000000
+++ xsltutils.c 2006-04-09 09:20:47.000000000 -0400
@@ -1924,14 +1924,13 @@
     xmlXPathContextPtr xctxt;
     xmlXPathCompExprPtr ret;

-    if (style != NULL)
-       xctxt = xmlXPathNewContext(style->doc);
-    else
-       xctxt = xmlXPathNewContext(NULL);
+    xctxt = (xmlXPathContextPtr)
+    memset(xctxt, 0 , (size_t)
     if (style != NULL)
        xctxt->dict = style->dict;
     ret = xmlXPathCtxtCompile(xctxt, str);
-    xmlXPathFreeContext(xctxt);
      * TODO: there is a lot of optimizations which
should be possible
      *       like variable slot precomputations,
function precomputations, etc.


Also, on a similar topic, is the precomputation of the
whole stylesheet required to do a transformation?
Let's say that I have a very large stylesheet and only
10% of it is used during a transformation (for
example, because certain modes are never called).
Currently all the XPaths are precompiled even though
90% of them will never be used. Is there a way to
compile the XPaths *only* when they are used? I tried
to set nopreproc to 0 but that didn't seem to work.

As always, thanks for your help & for this very useful
library. Regards,

 Jerome Pesenti
 Chief Scientist
 Vivisimo, Inc

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

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