From: Charles Mills <cmills@...>
Date: 2004-12-02T00:44:32+09:00
Subject: Re: Improvements to the profiler [Was Re: profile]

On Dec 1, 2004, at 4:52 AM, Robert Klemme wrote:

>
> "Lothar Scholz" <mailinglists@scriptolutions.com> schrieb im 
> Newsbeitrag
> news:13616401843.20041201132350@scriptolutions.com...
>
>> RK>  - the profiler does take away some performance already and I
> suspect this
>> RK> feature would lead to even greater slowdown.
>>
>> Even at the moment the profiler is at a proof of concept level and
> absolute
>> unusable in programs that do a little bit more then "puts 'hello
>> world'". It slows down a program by at least a factor 50.
>>
>> Every solution that is based on "set_trace_func" is in my opinion just
>> rubbish. try this with an empty proc and see how it slows down the
>> program and you will understand.
>
> I *have* in fact used the profiler already.  I would not go so far as 
> to
> call it "rubbish".  It has its use although I'd readily admit that it's
> limited.  But it's not rubbish.  Java's hprof with cpu=times has 
> similar
> bad impacts on overall performance but it is useful in certain 
> situations.
> (I admit though that I use cpu=samples most of the time :-))
>
A little while back I told someone who was looking to speed up a Ruby 
script to run it with the profiler.... they thought the profiler was 
broken, because it took so long :)
A 10 second script turned into 5-10 minutes.  But in the end it did 
work and helped us tune the program and get some very significant speed 
ups... which is what matters.
On a side note, in my experience object creation and garbage collection 
(something that isn't really measured by the profiler) seems to have 
the biggest impact on speed.  If you can reduce the number of objects 
created, the GC spends less time marking and sweeping objects.

-Charlie