Robert Klemme
12/1/2004 4:00:00 PM
"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