Closed ermolaev closed 4 years ago
In general web apps tend to create one giant string from a bunch of db queries
yes, but not always, and creating a large string we add a measurement error in the benchmark, testing not only the database library
float = 1.0
int = 1
Benchmark.ips do |x|
x.report("integer") do |times|
i = 0
while i < times
int + int
i += 1
end
end
x.report("float") do |times|
i = 0
while i < times
float + float
i += 1
end
end
x.compare!
end
# Comparison:
# integer: 35359450.3 i/s
# float: 29289130.9 i/s - 1.21x slower
Benchmark.ips do |x|
x.report("integer") do |times|
i = 0
s = +''
while i < times
int + int
s << 1.to_s
i += 1
end
end
x.report("float") do |times|
i = 0
s = +''
while i < times
float + float
s << 1.to_s
i += 1
end
end
x.compare!
end
# Comparison:
# integer: 4273034.2 i/s
# float: 4082119.9 i/s - same-ish: difference falls within error
I am fine with creating a few other benchmarks then, as long as we leave the existing ones as is
I think you are missing some of the goal of the perf test. the idea here is to generate a giant string as efficiently as possible not lots of arrays.
This ensures every db adapter does exactly the same thing and measured against the same goal.
In general web apps tend to create one giant string from a bunch of db queries