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

[Daniel Veillard <veillard redhat com>]

On Tue, Feb 25, 2003 at 02:07:38PM -0500, Gennady Feldman wrote:
> 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...

  yeah something is taking too much CPU ... profile, there is no 
alternative, have fun, I did profiling for libxslt ...

> > >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? 

  My feeling is that you should do intermediary buffering in the 
I/O libxml2 custom wrapper. I bet that the Apache does some kind of flush on
any write and that kills performances for small writes which is basically
what the libxml2 serialization layer will do. Bufferize ...
  But again it's just guesses, only actually profiling the code will
give you teh real answer. And gaining 2-3ms might be a bad idea if it
destroy cache locality when running for real !

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/