On Sunday, Nov 2, 2003, at 15:57 Europe/Rome, Vadim Gritsenko wrote:
Stephan Michels wrote:
On Sun, 2 Nov 2003, Stefano Mazzocchi wrote:
On Saturday, Nov 1, 2003, at 23:29 Europe/Rome, Steve K wrote:
And finally, on a somewhat unrelated subject, one thing that I've
always wanted Cocoon to do may be possible if support for collecting
the XML at each pipeline step is added. To aid in debugging, I think
it would be very helpful to switch on some kind of debug mode, that
would cause a trace of what pipeline steps where executed and the
state of the XML at each step to be printed out at the bottom of each
page you output to the browser. This way it is easy for a developer
to see the path though the pipelines the request took, as well as a
snapshot of the XML each step of the way.
This is already there, althought somewhat hidden, check into the "profiler" block.
BTW, there is something that always bugged me about the profiler: the time that gives you is almost totally useless,
(IIRC) Stephan did a lot of work on how profiler counts time, and now it's not useless at all.
ah, didn't know that! I used it a while ago and it seemed to me that the numbers were totally silly.
Stephan, can you explain the changes (or point me to a message that explains it)? thanks.
For example, I recently used profiler with different XSLT engines and found out that XSLTC finally became a tad faster than Saxon. Also, I found couple of stylesheets which were rewritten as transformers to gain some speed improvements.
Very cool. Then I remove my proposal.
while the exposed view of the pipeline internals is a *great* debugging tool
Never tried it (yet)! :)
(some people do
it with views, but sometimes you don't know where the problem is so you
might want to see it all).
I propose two changes here:
1) rename the "profiling" pipeline into "debug"
+1
-0. Current name suits me well.
I see, but people that look for debugging the pipeline will not find it (since profiling is not the same as debugging).
Maybe "pipe-instrumentation"?
2) remove the timings (they don't make any sense)
-1, why do you think the timings are useless?! I done a lot of profiling
with it in the past, and found for example the problem with the use-store
paramter of the TaxTransformer.
-1, it's useful to me.
I remove my proposal after your comments above.
3) move the whole thing into core
-1, the core should only contain necessary components.
+1, I wouldn't mind seeing it in core. It's like instrumentation manager which is also in core.
which I would like to be moved away as well... maybe an "instrumentation" block with both? I don't know. WDYT?
-- Stefano.
