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

["Gennady Feldman" <gena01 lk net>]

[clipped]
> 
> > 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.
> 
Yes. I wanted to include more information in the message so that we know
how much output is generated and have approximate reference numbers.

[clipped]
> > 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 ?
> 
I think so, I am using the RPMs, but I can check to make sure. I tried
to time the performances and stuff and it seemed rather weird to see how
much overhead I am seeing in the apache module. My normal benchmark
value is ~140ms using ab. That's aprox 60ms for the transformation. and
when I did "time xsltproc....." I was getting somewhere around 100ms..
with xsltproc outputting to a file. Which means that there was a 40ms
overhead somewhere, besides 100ms includes starting a new process and
loading the libraries and stuff...

[clipped]
> >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.
> 
[clipped]

I actually pulled the idea/code from python wrapper where it takes the
output of the transformation and converts that to a python string. I
guess that I am still not sure what's the best aproach to this. The way
I see it is that by me using this method i can win 2-3ms on the output
alone, so this is indeed faster (vs using the output callbacks). Maybe
there is another way to do this, or should we maybe take a look at
fixing the performance on a library level? 

Frankly I am still not sure of the most efficient way of doing this,
other than allocating blocks of a certain size and then linking them in
a chain (linked list?). Actually now that I think of it, is there a way
for me to provide the output buffer and use some sort of a function w/ a
context to populate my buffer with the data. This is just looking at it
from a different side,i.e. me allocating a buffer, populating it and
sending it out to apache.(as a streaming filter?)

G.F. aka Gena01
http://www.gena01.com