New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow Object Instance Creation because of GC #1964
Comments
Here's my little benchmark require 'benchmark'
class TestObject
def initialize
@foo = 1
end
end
n = 10_000_000
Benchmark.bm do |x|
x.report('just create objects') do
n.times do
TestObject.new
end
end
x.report('append objects') do
ary = []
n.times do
ary << TestObject.new
end
end
x.report('append fixnum') do
ary = []
n.times do
ary << 1
end
end
end
Rubinius actually blows MRI away here in just creating objects. Appending objects to an array is 60% slower, but appending a
When I changed your script to look at the differences in time (naively) class TestObject
def initialize
@one_var = true
end
end
objects = Array.new
t = Time.now
until objects.size >= 10_000_000 do
objects << TestObject.new
if objects.size % 1_000_000 == 0
puts Time.now - t
puts "#{objects.size} objects created."
t = Time.now
end
end I saw
|
Another thing to take into consideration with benchmarks like this is that they probably are invalid. The use case where every object stays alive is not a common one. The Rubinius GC is a generational garbage collector that takes advantage of the fact that in almost every normal workload most objects don't live for a long time. Therefore that case is optimized for by allocating separate in a young object space that can be collected very fast. If every object stays alive, it means that they will be allocated in the young space, copied a number of times between them and then into the mature generation. This of course is a lot more activity than MRI does with a very simple allocator that allocates memory and never moves it around. Nevertheless, if you see performance issues in real life code, we're more than happy to dive into it and see what we can improve. It's just that with scripts like these, optimizing them has probably very little real life value and we'd rather focus on performance of real life code of people. |
Rubinius is slower at creating a large number of object instances [and not destroying them] than Ruby main. This appears in large part to be the GC.
Reproduce
Brief Object instance stress test script: https://gist.github.com/3921407
This script isn't exactly "real world", but any application that creates a large number of instances (e.g. Rails) could benefit from a speedup.
Observations
rubinius 2.0.0dev (1.9.3 9efd9d1)
You can see a -Xprofile run here: https://gist.github.com/3921425
ruby 1.9.3p194
Other Data
Other thoughts
I have not played around with the -Xgc configuration settings to see if any of those yield better performance.
The text was updated successfully, but these errors were encountered: