cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Profiling Pipeline [was Re: [RT] Unit testing and CocoonUnit]
Date Sun, 02 Nov 2003 16:07:52 GMT

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?


View raw message