Subject:running XSLT - time + memory measurements Author:L Chatelain Date:06 Nov 2006 03:37 PM
Hi,
I have just started using Stylus Studio 2007 XML Enterprise Suite and I have some questions about "real" time and memory usage measurements (I am using the Saxon 8.7.3 processor in Stylus Studio).
- How to run a transformation to find out the "real" time it takes? I have the "preview results" and "start debugging" options but both of them take a lot more time than if I run the transformation directly with saxon (8.8) without using Stylus Studio, even if I remove all profiling options. (I am not interested in the preview neither, especially when I run the transformation on large XML files!)
- Is there a way to get the information returned by the saxon performance tool (saxon8.jar -t), i.e. execution times and memory usage, without calling it as a custom processor? Is there any other solution to measure the memory usage?
Subject:running XSLT - time + memory measurements Author:L Chatelain Date:07 Nov 2006 06:28 PM
Thank you for your answer.
Sorry to insist but regarding the execution time I go back to my first question then which was:
- How to run a transformation to find out the "real" time it takes? I have the "preview results" and "start debugging" options but both of them take a lot more time than if I run the transformation directly with saxon (8.8) without using Stylus Studio, even if I remove all profiling options. (I am not interested in the preview neither, especially when I run the transformation on large XML files!)
I know you can see the total execution time in Stylus Studio, as well as the execution time for each node for example in the profiling, which is really nice, but I do have big differences in the total execution time if I run the transformation with Stylus Studio vs. if I run the transformation using saxon in the command line. I guess this is might be due to the preview or some debugging actions.
Subject:running XSLT - time + memory measurements Author:Tony Lavinio Date:07 Nov 2006 11:15 PM
Here's the problem:
In order to accurately measure execution time to the element, we've got
to run Saxon in debug mode, because otherwise the Saxon compiler
rearranges options, and we can't get an accurate call tree. But debug
is considerably slower and doesn't accurately reflect the order that
things get processed when run at full speed.
Also, collecting the profiling data does impose some overhead, as does
the backmapping support for output which we always enable.
We have investigated somewhat a mode where we run Saxon without
enabling backmapping, but that still won't get you an accurate profile.
Most of the time in Saxon is spent navigating the source document tree.
If you are serious about profiling in a non-debug environment, you
might want to try running Saxon straight from java and using the -Xprof
option.