internal/database was the slowest test package, and three retention tests were nearly all of it, at 9 to 15s each. Most of that went to seeding: they insert thousands of rows 500 per statement, and the SQLite driver (modernc.org/sqlite v1.28.0) finds each parameter's value by scanning the statement's arguments from the first until it reaches that parameter's, so binding grows with the square of the parameter count. At 50 rows per insert the same rows go in about three times faster; smaller batches gain nothing more. No test case or assertion changes, and the package's coverage is unchanged.
make test in a cache-defeated image build, two runs each, 1-minute host load on 48 cores in brackets:
before
after
whole step
103.0s (44-59), 78.2s (25-33)
73.2s (35-37), 85.4s (25-48)
internal/database
22.2s, 13.2s
7.4s, 7.3s
internal/handlers
14.5s, 7.3s
10.0s, 8.1s
internal/delivery
13.4s, 6.6s
6.6s, 6.2s
internal/ciscript
7.2s, 7.1s
7.1s, 7.1s
What still keeps the run above 20s: the step spends 54 to 76s before its first package reports, which is the cold -race compile of the tree at -p 4, so the whole-step figure moves with load more than with this change. internal/handlers is now slowest, its time spread over 151 tests with no single cause. internal/ciscript's 7.1s is the script under test retrying a failed read three times, 2s apart, which is what that test checks.
Deviation: the 90s timeout in script/test stays, per the plan on #198; the header records the new figures.
Model: opus-5-5
`internal/database` was the slowest test package, and three retention tests were nearly all of it, at 9 to 15s each. Most of that went to seeding: they insert thousands of rows 500 per statement, and the SQLite driver (`modernc.org/sqlite` v1.28.0) finds each parameter's value by scanning the statement's arguments from the first until it reaches that parameter's, so binding grows with the square of the parameter count. At 50 rows per insert the same rows go in about three times faster; smaller batches gain nothing more. No test case or assertion changes, and the package's coverage is unchanged.
`make test` in a cache-defeated image build, two runs each, 1-minute host load on 48 cores in brackets:
| | before | after |
| --- | --- | --- |
| whole step | 103.0s (44-59), 78.2s (25-33) | 73.2s (35-37), 85.4s (25-48) |
| `internal/database` | 22.2s, 13.2s | 7.4s, 7.3s |
| `internal/handlers` | 14.5s, 7.3s | 10.0s, 8.1s |
| `internal/delivery` | 13.4s, 6.6s | 6.6s, 6.2s |
| `internal/ciscript` | 7.2s, 7.1s | 7.1s, 7.1s |
What still keeps the run above 20s: the step spends 54 to 76s before its first package reports, which is the cold `-race` compile of the tree at `-p 4`, so the whole-step figure moves with load more than with this change. `internal/handlers` is now slowest, its time spread over 151 tests with no single cause. `internal/ciscript`'s 7.1s is the script under test retrying a failed read three times, 2s apart, which is what that test checks.
- Deviation: the 90s timeout in `script/test` stays, per the plan on https://git.eeqj.de/sneak/webhooker/issues/198; the header records the new figures.
Model: opus-5-5
internal/database/totals_test.go, the comment above seedExpiredEvents (the same sentence is in the commit message and the PR body): it says the SQLite driver finds each parameter's value "by scanning all of the statement's arguments". It does not. The driver's conn.bind goes through the arguments from the first one and stops when it reaches the one for that parameter, so the k-th parameter costs k steps. That is still why binding grows with the square of the parameter count, but the sentence describes the mechanism wrongly. Acceptable: say it scans the arguments from the first until it reaches that parameter's, in the comment and in the commit message.
Model: opus-5-5
1. `internal/database/totals_test.go`, the comment above `seedExpiredEvents` (the same sentence is in the commit message and the PR body): it says the SQLite driver finds each parameter's value "by scanning all of the statement's arguments". It does not. The driver's `conn.bind` goes through the arguments from the first one and stops when it reaches the one for that parameter, so the k-th parameter costs k steps. That is still why binding grows with the square of the parameter count, but the sentence describes the mechanism wrongly. Acceptable: say it scans the arguments from the first until it reaches that parameter's, in the comment and in the commit message.
Model: opus-5-5
internal/database was the slowest test package, and three retention tests were nearly all of it. Most of their time went to seeding thousands of rows 500 per INSERT: the SQLite driver finds each parameter's value by scanning the statement's arguments from the first until it reaches that parameter's, so binding grows with the square of the parameter count, and a 500-row insert carries several thousand. Seeding 50 rows per insert stores the same rows. No test case or assertion changes. The header of script/test records the new figures; its 90s timeout stays.
Model: opus-5-5
Reworded the sentence in the comment above seedExpiredEvents in internal/database/totals_test.go, and the same sentence in this PR body and in the branch's commit message: the SQLite driver now reads as scanning the statement's arguments from the first until it reaches that parameter's. Rebased onto next.
Model: opus-5-5
Reworded the sentence in the comment above `seedExpiredEvents` in `internal/database/totals_test.go`, and the same sentence in this PR body and in the branch's commit message: the SQLite driver now reads as scanning the statement's arguments from the first until it reaches that parameter's. Rebased onto `next`.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
internal/databasewas the slowest test package, and three retention tests were nearly all of it, at 9 to 15s each. Most of that went to seeding: they insert thousands of rows 500 per statement, and the SQLite driver (modernc.org/sqlitev1.28.0) finds each parameter's value by scanning the statement's arguments from the first until it reaches that parameter's, so binding grows with the square of the parameter count. At 50 rows per insert the same rows go in about three times faster; smaller batches gain nothing more. No test case or assertion changes, and the package's coverage is unchanged.make testin a cache-defeated image build, two runs each, 1-minute host load on 48 cores in brackets:internal/databaseinternal/handlersinternal/deliveryinternal/ciscriptWhat still keeps the run above 20s: the step spends 54 to 76s before its first package reports, which is the cold
-racecompile of the tree at-p 4, so the whole-step figure moves with load more than with this change.internal/handlersis now slowest, its time spread over 151 tests with no single cause.internal/ciscript's 7.1s is the script under test retrying a failed read three times, 2s apart, which is what that test checks.script/teststays, per the plan on #198; the header records the new figures.Model: opus-5-5
internal/database/totals_test.go, the comment aboveseedExpiredEvents(the same sentence is in the commit message and the PR body): it says the SQLite driver finds each parameter's value "by scanning all of the statement's arguments". It does not. The driver'sconn.bindgoes through the arguments from the first one and stops when it reaches the one for that parameter, so the k-th parameter costs k steps. That is still why binding grows with the square of the parameter count, but the sentence describes the mechanism wrongly. Acceptable: say it scans the arguments from the first until it reaches that parameter's, in the comment and in the commit message.Model: opus-5-5
8bd751d022to011a9b703fReworded the sentence in the comment above
seedExpiredEventsininternal/database/totals_test.go, and the same sentence in this PR body and in the branch's commit message: the SQLite driver now reads as scanning the statement's arguments from the first until it reaches that parameter's. Rebased ontonext.Model: opus-5-5
Review passed.
Model: opus-5-5