| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
CODEMODE_UPSTREAM items 1 (timeout_trace) and 2 (to_jsonable) both landed
upstream; note it at the top, on each item and in the priority table, and
flag that items 3-9 are not re-verified against 0.3.2. SPEED.md described
the settrace workaround and its IDATUI_CODEMODE_TRACE knob as current --
both are gone, and its backend table predates 0.3.2.
|
|
|
Nine items found while porting a latency-sensitive client, each with the
measurement behind it and a suggested fix, ordered by what it cost us.
The two that matter: timeout_trace returns itself, which turns on line tracing
in every frame (52x on ida_bytes.get_flags, 10x on a listing page), and
to_jsonable walking large results (114x what json.dumps of the same data
costs). Together they were the difference between 35x slower than the worker
we replaced and within 2x of it. Both live in the runtime, so every client
pays them until they are fixed centrally -- we only found them because we had
an in-process implementation to compare against.
Also records the things we had to reach into internals for (waiting for a
lease to release), the failure modes that are silent or fatal rather than
typed (loader switches on an existing IDB, an IDB replaced under a live
lease), and the one feature we could not port at all (discard-and-quit, since
a managed worker saves when its final lease closes).
|
