Ron Blaschke wrote: > Ross Gardler wrote: > > David, I am afraid to say I have not checked this out yet. Despite > > noting its existence and the effort you put into this (and the docs). > > > Can I make a suggestion? (I'll do this the first time I find the need to > > use this if it hasn't been done before me): > > > If we make an internal plugin of the profiler we can replace the > > necessary pipelines in that plugin. Then, to enable profiling all we > > need to do is add the plugin to forrest.properties. > > I am about to start working on a plugin. Actually, I thought I > could start last weekend, but didn't quite make it. > > Most things are straightforward. I'm only puzzled by the mix of input > plugin (ie, take data from the profiler data store and render it) and > internal plugin (ie, profile stuff and store results in profiler data > store). Can a plugin be both, input and internal? > Second, the profiler result page must be rendered last, or it wouldn't > contain all profile results. Don't know how to do this, yet.
I find that the Cocoon Profiler is useful to look at the processing for a single page, i.e. forrest clean, forrest run, request index.html a few times, then look at cprofile.html and follow the results. Doing it for the whole of 'forrest site' might be useful in a different way - don't know yet. -David > > We could later enhance this by adding a command line switch to run with > > the profiler enabled. > > > In addition to making it easier to run the profiler, it will also keep > > the sitemaps a little more tidy. > > And forrest-core.xconf and lib/core, too, but only slightly. > > Ron >
