hi,I want to use ruby’s garbage collector
GC.start
but when use it,and when not use it?
hi,I want to use ruby’s garbage collector
GC.start
but when use it,and when not use it?
From: “gz zz” [email protected]
hi,I want to use ruby’s garbage collector
GC.start
but when use it,and when not use it?
Garbage collection in ruby is automatic. You can turn it off
(GC.disable) or turn it on (GC.enable) or tell it to run “right now”
(GC.start). But normally you just leave it on by default and
let it collect automatically. You normally don’t need to mess with
it unless you have some special situation.
Regards,
Bill
Thank you.
I only see rails use the ‘GC.start’ in my all ‘gems’.e.g.
def test_time_recognition
n = 10000
if RunTimeTests
GC.start
rectime = Benchmark.realtime do
n.times do
rs.recognize_path(“content”)
rs.recognize_path(“content/list”)
rs.recognize_path(“content/show/10”)
rs.recognize_path(“admin/user”)
rs.recognize_path(“admin/user/list”)
rs.recognize_path(“admin/user/show/10”)
end
end
puts “\n\nRecognition (RouteSet):”
per_url = rectime / (n * 6)
puts “#{per_url * 1000} ms/url”
puts “#{1 / per_url} url/s\n\n”
end
end
From: “gz zz” [email protected]
rs.recognize_path("content/show/10")
end
It’s doing GC.start there right before the Benchmark starts, just to
help achieve a more consistent starting point, for measuring the
elapsed time.
Notice it only does the GC.start when benchmarks are being run.
Regards,
Bill
On Thursday 28 June 2007, Bill K. wrote:
rs.recognize_path("content") puts "#{1 / per_url} url/s\n\n"
end
endIt’s doing GC.start there right before the Benchmark starts, just to
help achieve a more consistent starting point, for measuring the
elapsed time.Notice it only does the GC.start when benchmarks are being run.
It may be difficult to benchmark (or profile for that matter) code under
GC: if the GC runs, you can get more than 200ms accounted to whichever
method was being run.
If you can afford the memory allocation of your benchmarked code, try
GC.start ; GC.disable before starting the bench.
Sylvain J. wrote:
It may be difficult to benchmark (or profile for that matter) code under
GC: if the GC runs, you can get more than 200ms accounted to whichever
method was being run.If you can afford the memory allocation of your benchmarked code, try
GC.start ; GC.disable before starting the bench.
Given that the GC runs during real world operation, and that benchmarks
are generally about
determining whether some code will perform acceptebley in a real
situation, I’m not sure the above
is great advice. Seems to me it would be better to write benchmarks that
run for an amount of time
that is sufficient to ensure that the overhead of GC is consistent
between runs of the benchmark.
For example, don’t write a benchmark that takes 0.001 seconds. Write one
that takes 30 seconds, or
whatever. I’m not experienced enough with ruby yet, to know what a
sensible duration is.
cheers,
mick
vice.
Seems to me it
would be better to write benchmarks that run for an amount of time that is
sufficient to ensure that the overhead of GC is consistent between runs of
the benchmark.
The problem is that, in real programs, the code snippet will not be the
only
part of the code allocating objects. When the GC runs, you pay for all
the
objects present in the system. Measuring the time the GC takes in a
controlled situation like a benchmark will not give you any information
on
how much impact your code will have w.r.t. GC in a real program.
For example, don’t write a benchmark that takes 0.001
seconds. Write one that takes 30 seconds, or whatever. I’m not experienced
enough with ruby yet, to know what a sensible duration is.
The problem is not the duration, but the amount of objects created.
IMO, if you’re interested in benchmarking GC effects, benchmark your
code in
both time and object allocation. You’ll see the kind of tradeoff that
one
solution has w.r.t. another. (ok: it runs 10 times faster but allocates
a lot
of objects)
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs