From: Robert Klemme <bob.news@...>
Date: 2004-12-02T01:02:52+09:00
Subject: Re: Improvements to the profiler [Was Re: profile]


"Charles Mills" <cmills@freeshell.org> schrieb im Newsbeitrag
news:E23078B9-43AF-11D9-AA47-000A95A27A10@freeshell.org...
> 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 :)

If you have suspects and the profiler slows down too much, you can even
time manually with a helper method like this:

module Kernel
private
  def time(msg)
    t = Time.now.to_f
    begin
      return yield
    ensure
      t = Time.now.to_f - t
      $stderr.puts "#{msg} took #{t} sec"
    end
  end
end

>> time("print 100 x") { 100.times { print "x" } ; puts }
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxx
print 100 x took 0.00399994850158691 sec
=> nil

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

Yeah, it's the same with Java.

Kind regards

    robert