Speed up two slowest specs (~2.2s combined)#282
Closed
yahonda wants to merge 2 commits intorsim:masterfrom
Closed
Conversation
The "should safely close cursors in threaded environment" example in spec/plsql/schema_spec.rb spawns two threads that call DBMS_SESSION.sleep (or DBMS_LOCK.sleep on pre-18c) and joins them. The point of the test is that two concurrent calls on the same connection don't trip the cursor pool — the sleep durations are only there to keep both calls in flight at once. The original 1- and 2-second sleeps dominated the suite at ~2.05s out of ~10s total (~21%, the slowest example by a wide margin). Drop them to 0.1s and 0.2s, which still gives 100ms of guaranteed-overlap and a 100ms ordering gap between the two threads — far more than OS scheduling needs to keep both in flight. Verified stable across three back-to-back runs at ~0.29s each. Net effect: full suite drops from ~9.93s to ~8.08s (~19% faster); this example moves from #1 to rsim#4 in the slowest-examples profile. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "should log output when database version is less than 10.2" example in spec/plsql/schema_spec.rb stubs database_version to [9, 2, 0, 0] so dbms_output retrieval falls into the per-line DBMS_OUTPUT.GET_LINE loop in PLSQL::ProcedureCall#dbms_output_lines instead of the batched DBMS_OUTPUT.GET_LINES path used on 10.2+. With times = 2_000 each iteration is one parse-and-exec round-trip, which is what made this example the second-slowest in the suite at ~0.42s. The intent of the example is to verify the alternate per-line code path works at all — 100 iterations exercise it just as well as 2_000 (the buffer-size assertions live in the unmocked examples right above). Drop times to 100. Verified stable across three back-to-back runs at ~0.09s each. After this and the threaded-cursor change, the slowest-examples profile is much more even (top spec is now ~0.33s). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Let's avoid this kind of micro fixes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two independent test-only changes that bring the spec suite from ~9.93s down to ~7.7s, with a much flatter slowest-examples profile afterwards.
1. Threaded-cursor spec — drop sleep durations
should safely close cursors in threaded environment(spec/plsql/schema_spec.rb:255) spawns two threads that callDBMS_SESSION.sleep(orDBMS_LOCK.sleepon pre-18c) and joins them. The point is that two concurrent calls on the same connection don't trip the cursor pool — the sleep durations are only there to keep both calls in flight at once.The original 1s / 2s sleeps dominated the suite at ~2.05s (the slowest example by a wide margin). Drop to 0.1s / 0.2s — that still keeps both threads in flight for 100ms with a 100ms ordering gap, far more than OS scheduling needs.
Result: this example: ~2.05s → ~0.29s (verified stable across 3 back-to-back runs).
2. Pre-10.2 dbms_output spec — drop iteration count
should log output when database version is less than 10.2(spec/plsql/schema_spec.rb:353) stubsdatabase_versionto[9, 2, 0, 0]so dbms_output retrieval falls into the per-lineDBMS_OUTPUT.GET_LINEloop inPLSQL::ProcedureCall#dbms_output_linesinstead of the batchedGET_LINESpath used on 10.2+. Withtimes = 2_000each iteration is one parse-and-exec round-trip.The intent of the example is to verify the alternate per-line code path works at all — 100 iterations exercise it just as well as 2_000 (the buffer-size assertions live in the unmocked examples right above).
Result: ~0.42s → ~0.09s (verified stable across 3 runs).
Combined impact
Test plan
🤖 Generated with Claude Code