Measuring and improving Forrest build times (was: Quick glimpse at Forrest's build times)

[Ron Blaschke <ma...@rblasch.org>]

Thursday, August 18, 2005, 5:58:54 PM, David Crossley wrote:
> Ross Gardler wrote:
>> David Crossley wrote:
>> >Ron Blaschke wrote:

>> Thought for the future when this is sorted out. Can we create a new test
>> target that will do this profiling for us?

>> That way, each time we upgrade a dependency we can see if it impacts 
>> performance.

> Yep i wondered that too. We can take it a step further
> and have it running on our zone and save a set of daily
> logfiles. Perhaps analyse them with Ron's script.

The script is written in perl, and currently in no condition to show
someone else. ;-)  If you think the script is helpful, I'll polish it
a bit, so we can use it.

Currently, I guess there are three ways we can get numbers:

1) CPU profile with a real profiler
  Should give the most detailed results, but probably not useful for
  daily use.  This is what I am currently working on.

2) Cocoon profiler block
  Judging from the demo page, this might be what we look for.

3) "The script"
  The numbers print by Cocoon, and used by my script, are probably
  equal to the total times as output by the profiler block.
  It's simple, and if we average a few runs probably quite effective.

Ron

Re: Measuring and improving Forrest build times

[Ross Gardler <rg...@apache.org>]

Ron Blaschke wrote:
> Thursday, August 18, 2005, 5:58:54 PM, David Crossley wrote:
> 
>>Ross Gardler wrote:
>>
>>>David Crossley wrote:
>>>
>>>>Ron Blaschke wrote:
> 
> 
>>>Thought for the future when this is sorted out. Can we create a new test
>>>target that will do this profiling for us?
> 
> 
>>>That way, each time we upgrade a dependency we can see if it impacts 
>>>performance.
> 
> 
>>Yep i wondered that too. We can take it a step further
>>and have it running on our zone and save a set of daily
>>logfiles. Perhaps analyse them with Ron's script.
> 
> 
> The script is written in perl, and currently in no condition to show
> someone else. ;-)  If you think the script is helpful, I'll polish it
> a bit, so we can use it.
> 
> Currently, I guess there are three ways we can get numbers:
> 
> 1) CPU profile with a real profiler
>   Should give the most detailed results, but probably not useful for
>   daily use.  This is what I am currently working on.
> 
> 2) Cocoon profiler block
>   Judging from the demo page, this might be what we look for.

Your idea of creating a plugin to do this profiling is a good one. I've 
not looked at what is involved, but I like the idea.

> 3) "The script"
>   The numbers print by Cocoon, and used by my script, are probably
>   equal to the total times as output by the profiler block.
>   It's simple, and if we average a few runs probably quite effective.

4) Use an Open Source profiler that provides and XML output and create a 
plugin that way.

Ross