cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject SOT: TODO medium priority issue
Date Thu, 05 Apr 2001 13:41:20 GMT
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.

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

View raw message