forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Profiling Forrest [FOR-572]
Date Fri, 26 Aug 2005 07:23:38 GMT
Ron Blaschke wrote:
> 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.

Some Forrest developers definitely want to see these
numbers and do want to get their hands dirty with Cocoon.
There must be a lot that we can do to speed it up, e.g.
tune our cache; more efficient sitemap processing; etc.

> 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.

We have talked about this before, having a "benchmarking site".
It would need to not be changing too often.

> 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

Good stuff Ron. How shall we proceed? I could get the
shell of a benchmark site started ('forrest seed-benchmark').


View raw message