cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Profiling Pipeline [was Re: [RT] Unit testing and CocoonUnit]
Date Mon, 03 Nov 2003 11:42:05 GMT

On Monday, Nov 3, 2003, at 11:53 Europe/Rome, Stephan Michels wrote:

>
>
> On Sun, 2 Nov 2003, Stefano Mazzocchi wrote:
>
>>
>> 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.
>
> All I made was to use XMLByteStreamInterpreter/Compiler as a buffer,
> measure each sitemap component separate.
>
> G -> Buffer1
>
> Buffer1 -> T1 -> Buffer2
>
> etc.
>
> The side effect is that you can use these buffers to get intermediate
> document as debug information.
>
> (Buffer(n) -> Buffer(n+1) take in most cases less than a 1ms)
>
> I also measure the time for setup(), which needs in some special cases
> 400 times more time.

Ok, great. Makes perfect sense. Sorry for the noise.

--
Stefano.


Mime
View raw message