diff options
| author | blasty <blasty@local> | 2026-08-09 22:37:44 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-08-09 22:37:44 +0200 |
| commit | 61837c0cc931a2e2472d23e830db240da0d7b8e9 (patch) | |
| tree | ae625613a0631ae18cbfe4becdc79edcc51b3caa /tests/test_codemode_client.py | |
| parent | Docs: correct the stale --fast check counts (302/257 -> 380) (diff) | |
| download | ida-tui-61837c0cc931a2e2472d23e830db240da0d7b8e9.tar.gz ida-tui-61837c0cc931a2e2472d23e830db240da0d7b8e9.tar.xz ida-tui-61837c0cc931a2e2472d23e830db240da0d7b8e9.zip | |
Docs: re-check ALL nine upstream findings against 0.3.2
Items 1-2 were marked fixed; 3-9 were left 'not re-verified', which was a
gap rather than a finding. Checked all seven.
Item 3 is also FIXED, and by a lot: a same-box A/B (roll the editable
checkout back to 4195f21, measure, roll forward) puts
execute_python('result = 1') at 2.055ms on 0.3.1 and 0.294ms on 0.3.2 --
7.0x, now about the cost of a bare HTTP GET. The 0.3.1 column reproduces
the originally documented 2.025ms almost exactly, which is what makes the
0.3.2 column believable. So the execute_sync marshalling that was ~93% of
the floor is gone, and the 'never make a call per row' rule is much weaker.
Items 4-9 are open by construction: client/registry/resolver/server/
database/worker .py are byte-identical between 0.3.1 and 0.3.2, and all six
items live in those files. Recorded that as the cheap re-check recipe for
the next upstream pull.
SPEED.md taught the obsolete 2ms floor as a design rule; corrected, with a
warning not to go rewrite working batched code to be chatty.
Diffstat (limited to 'tests/test_codemode_client.py')
0 files changed, 0 insertions, 0 deletions
