A parsed stylesheet can be reused for any number of possibly concurrent
transactions.
Of you mean saving a compiled stylehseet to disk in a non-standard
format:
  1/ it's non standard
  2/ it's *not* worth it in my experience considering
     libxml2/libxslt speed of parsing and building the compiled form

  So answer, there is no bug here, and trying to work around some
inefficiencies in Java can lead to bad workaround, still trying to 
use those workaround in other environment sounds a really bad idea.

Daniel

This is not a bug, it is an enhancement request.

Each time an XSL transformation is performed it has to read and parse/compile the stylesheet, which means a lot of duplicated processing if the same stylesheet is used over and over again. If a stylesheet can be read once, compiled once, then held in memory (or some sort of cache) then all subsequent accesses of that stylesheet will be much faster.

My application has 500+ screens but only uses a dozen or so stylesheets, so the performance impact would be very beneficial.

> Each time an XSL transformation is performed it has to read and parse/compile
> the stylesheet which means a lot of duplicated processing if the same
> stylesheet is used over and over again.

Wrong . A parsed stylesheet can be used as many time as needed as I stated in
my answer. A parsed stylesheet is *read only* w.r.t. transformations. A lot
of application actually reuse libxslt compiled stylesheets.

> If a stylesheet can be read once, compiled once, then held in memory
> then all subsequent accesses of that stylesheet will be much faster.

The stylesheet can be kept in memory and reused as many times as needed
Please read my answers before stating I am wrong !
: A parsed stylesheet can be reused for any number of possibly concurrent
: transactions.
First sentence of answer #1 apparently what you are asking in #2

And I still maintain that loading a normal stylesheet from disk, or loading
a "precompiled stylesheet" from disk would have nearly the same cost so
no enhancement, and it's not worth inventing a non-standard serialization
for stylehseet.
Keep your 12 compiled stylesheets in memory and stop arguing on API based
on the fact that you know the Java API but fail to understand the libxslt
API, thank you !

Daniel

Your reply is *most* unhelpful. Each time I perform  an XSL transformation the XSL stylesheet is (a) read from disk, (b) parsed to check for syntax errors, then (c) executed. Step (a) may be circumnavigated if the underlying OS can serve the stylesheet from its file cache instead of re-reading the disk, but step (b) always has to be performed, which is an overhead.

You say that "A parsed stylesheet can be reused for any number of possibly concurrent transactions", but my point is that the transactions are not concurrent, they are sequential, which means that the stylesheet has to be parsed each time, which is an overhead whichever way you look at it.

I am using the libxslt librares that come with PHP, and there is nothing in the PHP documentation about using a cache of parsed stylesheets to avoid the overhead of re-parsing each time. I have checked the documentation for libxslt and I see absolutely nothin there about building, using and clearing a cache of parsed stylesheets, therefore I can only conclude that there is no such thing.

Do not try to tell me that utilising a cache of pre-parsed stylesheets would not produce any savings, oherwise scripting languages such as PHP would not bother with an opcode cache of pre-parsed scripts to provide increased performance.

If it is possible to cache a parsed stylesheet so that it does not have to be re-parsed each time, then why doesn't the documentation say so?

If it does use a cache, then how can it be flushed and rebuilt for those rare occasions when one of my stylesheets changes and so must be re-parsed?

I don't understand your cdomment in #4
In libxslt the process of generating a compiled stylesheets
is clearly a separate step from the process of running 
a transformation. So I don't undestand your comment.
It's hard to be helpful when one doesn't understand each other. I
still maintain there is no bug nor reason for an enhancement here
just confusion on your part on the library usage. Are you sure
you are using libxslt ???

(a) and (b) are in the compilation phase which produces a compiled
  stylesheet
(c) is happening when asking for transforming a parsed document

I don't see how you managed to get (a), (b) and (c) glued in a single
step, it's not libxslt normal processing.

There is no cache, you just keep the pointer resulting from the compilation
after step (a) and (b) and reuse it for as many (c) steps as needed
before freeing it.

You need help on using the API, bugzilla is not the proper place
to request help, there is a mailing-list for that as pointed
out in http://xmlsoft.org/XSLT/bugs.html

Daniel

"I am using the libxslt librares that come with PHP"

Maybe the PHP bindings don't separate compilation and transformation.
You should ask for enhancement at the PHP level, this is not 
a bug or problem at the GNOME C level, which is what this bugzilla
is all about. I was unhelpful because you didn't gave me the
basic infoamtions and used the wrong channel for the request.

  Sorry about this, this is not a libxslt problem, but possibly
a PHP binding one.

Daniel

Now we're getting somewhere. I did not know whether the relevant API's existed in libxslt or not, and searching through the documentation was a waste of time as it gives intimate details of each API without giving any overview. I could not see any mention of a cache for holding compiled stylesheets, so I simply presumed there wasn't one.

Now I know that the API's do exist but that the PHP implementation does not make use of them, I shall take my problem to the PHP developers. Thanks.