cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: SOT: TODO medium priority issue
Date Thu, 05 Apr 2001 14:34:45 GMT
Berin Loritsch wrote:
> SOT (Semi-Off-Topic)
> In Cocoon 2's TODO list under "medium" prioriy, it meantions that
> we should have this great and mighty profiler.  In the past I have
> given it allot of thought, because I wanted to implement it.
> Unfortunately, due to the SAX model, this feature will add more
> complexity than is really worth.  The reason is that every stage
> is executed simultaneously.  A Generator's startElement() will
> propogate through the different stages and cause the Transformers
> and Serializers to act on it before the next SAX event is called.
> We can easily approach a rough view of the performance at setup
> and page generation levels, but there is nothing that will let
> us easily split generation from transformation and serialization.
> Consider the following simple sequence diagram:
> Generator       Transformer       Transformer       Serializer
>     |                |                 |                |
>     | start "foo"    |                 |                |
>     +--------------->|  start "foo"    |                |
>     |                +---------------->|   start "bar"  |
>     |   end "foo"    |                 +--------------->|
>     +--------------->|    end "foo"    |                |
>     |                +---------------->|     end "bar"  |
>     |                |                 +--------------->|
>     |                |                 |                |
> At this approach, you would have to find the difference in
> timings.  You find the timing it takes for the "start:foo"
> event from the Generator to execute from beginning to end,
> and repeat the results for each stage.  The timing for the
> second transformer to call and return the "start:foo" event
> is the time it takes for the serializer to process.  You
> subtract that time from the time for the first transformer
> to call and return the "start:foo" event and you have how
> long the second transformer took.  You repeat the algorithm
> by subtracting the cumulative time for the first transformer
> to call and return the "start:foo" event from the total time
> for the Generators call.
> You have to repeat that algorithm for EACH SAX EVENT, and add
> the cumulative results for each stage to find out how long the
> relative times are.  This will degrade performance so bad,
> Cocoon 2 will seem like it is crawling.
> The biggest problem with that is what if one of the
> transformation stages removes the SAX event from the pipeline?
> You would find out how long the processing spent with each
> step, and with each SAX event.  This will help you determine
> EXACTLY where in the page the slowdown occurs.  The other
> issue is how do we measure general delays between SAX events
> for the Generator?  My assumption is that the clock would
> have to be continually ticking for the generator and only
> subtract out the results for each stage.
> The good news is that with the skeleton for the new pipeline
> that we now have in CVS, we can implement the algorithm in
> a ProfilingEventPipeline object and possibly a
> CacheProfilingEventPipeline.  Stream profiling is very easy,
> so it is not as major a concern.

Exactly the beauty of the component management in C2 :) Think also of
replacing the NullSAXConnector with a TimingSAXConnector for measurement
together with your ProfilingEventPipeline which only have to collect the
timings from those SAXConnectors after processing the pipeline to report
the statistics. 

A future CachingEventPipeline will probably use different instances of
SAXConnectors for measurement of cache efficiency, for cache "tee"ing
and cache replay.


> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message