Skip to content
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

Optimize the statement check for a non-discarded database #565

Merged
merged 1 commit into from
Sep 19, 2024

Conversation

flavorjones
Copy link
Member

Closes #564 which pointed out a performance regression from #558.

This also restores the ability (now tested!) to call Database#close successfully and defer its cleanup until after Statements are closed, which was the promise of #557 and sqlite3_close_v2.

Running the benchmark @tenderlove wrote for #564:

#!/usr/bin/env ruby

require "bundler/inline"

gemfile do
  source "https://rubygems.org"
  gem "sqlite3", path: "."
  gem "benchmark-ips"
end

require "sqlite3"
require "benchmark/ips"

file = "/tmp/test.sqlite3"

begin
  File.unlink file
rescue
  nil
end

db = SQLite3::Database.new file
db.execute "create table foo (id int)"

1000.times do |i|
  db.execute "insert into foo (id) values (#{i})"
end

Benchmark.ips do |x|
  x.report("selecting") {
    db.execute("select * from foo").to_a
  }
end

db.close

On 480f3e7 after sqlite3_open_v2 was introduced by #557:

ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]
Warming up --------------------------------------
           selecting   533.000 i/100ms
Calculating -------------------------------------
           selecting      5.306k (± 1.3%) i/s  (188.47 μs/i) -     26.650k in   5.023715s

On 81ea485 after fork protection was introduced by #558, performance regressed:

ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]
Warming up --------------------------------------
           selecting   329.000 i/100ms
Calculating -------------------------------------
           selecting      3.261k (± 3.4%) i/s  (306.66 μs/i) -     16.450k in   5.051880s

On 56d47a6 in this PR, performance is restored.

ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]
Warming up --------------------------------------
           selecting   548.000 i/100ms
Calculating -------------------------------------
           selecting      5.476k (± 1.7%) i/s  (182.61 μs/i) -     27.400k in   5.004987s

This also restores the ability (now tested!) to call Database#close
successfully and defer its cleanup until after Statements are closed,
which was the promise of #557 and sqlite3_close_v2.

Closes #564
@flavorjones flavorjones force-pushed the flavorjones-optimize-discarded-db-check branch from 806657c to af548cf Compare September 19, 2024 12:45
@flavorjones
Copy link
Member Author

@tenderlove I'd like to merge this and cut an RC2 today, but would love your eyes on this if you get a chance.

@flavorjones flavorjones merged commit 98d24ce into main Sep 19, 2024
108 checks passed
@flavorjones flavorjones deleted the flavorjones-optimize-discarded-db-check branch September 19, 2024 20:49
@tenderlove
Copy link
Member

@flavorjones sorry was busy today. This is great though, thank you for fixing it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use sqlite3_close instead of sqlite3_close_v2?
2 participants