Re: [xslt] xml/xst timings reported by xsltproc.

[Daniel Veillard <veillard redhat com>]

On Tue, Feb 25, 2003 at 11:30:40AM -0500, Gennady Feldman wrote:
> This is the my xml file:
>  59834 Feb 24 14:40 nstate.xml
> 
> xsltproc from command-line gives me:
> [clipped]
> Parsing document nstate.xml took 13 ms
> [clipped]

  sounds normal.

> Time per request:       117.400 [ms] (mean)

This include the emitting request, parsing it, loading, doing the
transform, saving the transform result and sending it back I assume.

> Just to show the difference in the numbers. it seems that by caching
> parsed XML references we are winning ~27ms. And the fluctuations are

  Hum, 

> when each process reloads the updated copy of the XML file. So some of
> the requests use a cached copy (114ms) vs parsing (141ms). For me the
> curious thing is why am I seeing such a big difference between what
> xsltproc says and what I am getting from ab.

Are you sure you use the same shared libraries ? With the same optimization
level ?

> P.S. On another note, here is a quick question. I have switched the code
> in the development version to stay away from using OutputBuffer and it's
> callbacks and use xsltSaveResultToString() instead. This appears to be
> aprox 2-3ms performance win since we generate everything in one big
> chunk vs allocating and using callbacks for small bunches of output. The
> real question is how efficient is the code for xsltSaveResultToString()
> and does it use realloc() or does a quick precompute pass to calculate
> the size of the buffer to allocate for the output? And is there a better
> way of doing this?

  The problem is that for large transforms you will end up eating more
memory. The buffer allocation is exponential realloc with a size doubled
each time and starting at 4KB.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/