forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Blaschke <mailing-li...@rblasch.org>
Subject Re: Profiling Forrest [FOR-572]
Date Tue, 23 Aug 2005 09:42:39 GMT
Monday, August 22, 2005, 12:57:34 PM, David Crossley wrote:

> Diwaker Gupta wrote:
>> 
>> So here's what I have right now:
>> 
>> o I can do a simple ./build.sh jar.debug -- this creates a "debug" version of 
>> Forrest. When you next run Forrest, the data will be automatically logged. 
>> Where and how and what to log is all configurable via an XML file
> [snip]
>> So what do devs think of this? If we find this valuable, I can commit 
>> everything to SVN. 

> Would you please briefly explain what is needed.

> We could probably add shell script options that run
> certain profilers if the user has them installed,
> i.e. we provide the configuration files for various
> supporting tools and our shell script knows how to
> run the user-supplied tool.

Thanks Diwaker, for having a look at this.

There are two things I'd like to mention here.  First, usually a
profiler at this low level (the VM) uses the JVMPI or JVMTI, and is
integreated via -Xrun... or -agentlib:... VM options, which I usually
simply set via forrest.jvmargs.
Helpful scripts would be good if a more "exotic" profiler is used,
like JRat.  Those who work with profilers probably have their
favorite, and know how to integrate it.

Second, I am not sure things proceed into the right direction, but
this is just my opinion - feel free to disagree.  To make sense of
these VM profiling data one usually has to know quite a bit how the
internals work, maybe more than Forrest developers want to.  You'd
usually want the Cocoon source on your disk, if your are looking at
these numbers.  But I want to see some detailed profile myself, to
make sure my guess is right.

When profiling Forrest I'd go some other way, like this:

Create a benchmark site.  A site specifically aimed to get profiling
numbers.  A first shot might be to create separate directories for
each feature, or plugin, to group results.
I'd like to see numbers like the following.
    Total time for whole benchmark site
    Time for each directory
    Time for each document
    Time for each pipeline step of a document
    ... [add your favorite number here]

Then we can run different Forrest versions against the benchmark site,
and compare the numbers.

The Cocoon profiler block might be just right for that, but I haven't
checked.

I'd guess there would be some pipeline steps that would be slow.
Depending on the type of transformer, a XSLT profiler or a VM profiler
should be used; or just a good old look at the code. ;-)

A complete VM profile should only be necessary if there's something
strange going on with Cocoon, that we can't explain.

Just my thoughts,
Ron




Mime
View raw message