perf(hooks): ~60 ms of the 90 ms Bash-group baseline is module import + compiling 188 module-level regexes per dispatch

[devseunggwan]

Symptom

A no-op Bash tool call (ls -la) costs 90 ms in the PreToolUse(Bash) dispatch group at 9a75c74. That is acceptable, and far better than the pre-#613 ~35 cold starts — this issue records where the remaining fixed cost sits so it is a known quantity rather than an assumption.

cProfile of hooks/_lib/_dispatch.py PreToolUse Bash claude with a trivial command:

Component	Time
python3 -c pass	8 ms
import _hook_utils alone	26 ms
import _hook_utils + _transcript + _git + _fire_ledger + _paths	42 ms
_load_main × 55 members (exec of each impl.py)	84 ms cumulative
of which re.compile × 188	58 ms
hook logic for ls -la	remainder, ~10 ms

Python's re cache is per process, and every dispatch is a fresh process, so all 188 module-level patterns across the 55 members are recompiled on every Bash tool call, whether or not the member's cheap discriminator would have returned early.

Options (none urgent)

1. Lazy compile: wrap the heavy patterns in a functools.lru_cache'd accessor so a member that returns at its cheap gate (tool_name != "Bash", no trigger token in the command) never compiles them. The shared ones in _hook_utils are the biggest single block.
2. Precompiled cache: not available for re without pickling tricks; not recommended.
3. Fewer members: the hook-prune audit (docs/hook-prune-audit.md, chore(hooks): evidence-based hook prune audit #713) is the structural lever — every dropped member is one less exec + compile.

Suggest deferring unless the baseline drifts past ~150 ms; the two transcript-scanning members (#1277, #1278) dominate real-world latency by an order of magnitude.

References

• perf(hooks): single-process Bash hook dispatcher #613 (single-process dispatcher), chore(hooks): evidence-based hook prune audit #713 (prune audit), fix(hooks): per-member deadline for the Bash dispatch group #1167, perf(hooks): block-commit-without-codex-review materializes the whole transcript and json.loads every line #1277, perf(hooks): unenforced-step-advisory re-parses the whole session from byte 0 on every git commit #1278

[devseunggwan]

Re-measured at cf4f521: still under this issue's own deferral threshold

The issue set its own trigger — "defer unless the baseline drifts past ~150 ms".
Re-measured today on the same shape of call (ls -la, PreToolUse / Bash
group), 12 runs each, telemetry redirected to a scratch path so the operational
ledger stayed clean:

$ python3 - <<'EOF'
… subprocess timing, 12 runs, min and median …
EOF
python3 -c pass      min   12.5 ms   median   15.5 ms
PreToolUse/Bash disp min   90.9 ms   median  108.9 ms
dispatch above floor  min   78.4 ms   median   93.4 ms

Plainly: a no-op Bash call still costs about 90 ms in the dispatcher, the same
figure this issue recorded at 9a75c74. It has not drifted, so by the issue's
own criterion no work is warranted yet.

The one number that did grow is the regex count, and it grew a lot:

$ python3 - <<'EOF'
… count `^NAME = re.compile` per file across members and _lib …
EOF
distinct member impl.py files: 98
module-level re.compile in members: 285
module-level re.compile in _lib: 12
total: 297

188 → 297 module-level patterns, across 98 member files rather than 55. That
the wall-clock held flat while the compile count rose ~58% is worth stating
rather than glossing: whatever headroom option 3 (fewer members) would have
bought has been spent, and the next 100 patterns will not be free.

Suggested reading of this: keep the issue open as the record it was written to
be, and re-run the two blocks above when the group next grows. The lazy-compile
option (1) stays the first lever if the median crosses 150 ms.

Measurement caveat: the first pass of this benchmark, run cold, reported
160–210 ms for the dispatcher and 80 ms for python3 -c pass — a floor 10×
the warm one. Both numbers above are warm-cache minima and medians; a cold
first call on this host costs roughly twice the warm figure, which matters for
the very first Bash call of a session but not for the steady state.

[devseunggwan]

Review — 기준선 재측정 (rev 3)

Verdict: Reject — 이슈 본문이 스스로 건 가드(Suggest deferring unless the baseline drifts past ~150 ms)가 발동하지 않았습니다. 측정 커밋 9a75c74 와 현재
9738307 을 같은 기계·같은 방법으로 나란히 재니 드리프트가 없고(median 86.3 →
78.1 ms), 멤버별로 봐도 지배적 병목이 없어 옵션 1 을 구현할 근거가 서지 않습니다.
기록용 이슈로서의 가치는 남아 있으므로 닫지 않고 이 재측정을 기준선으로 남깁니다.
Tasks 표는 본문의 "Options" 3개를 그대로 행으로 씁니다.

Axis	Ground	Result
Need	가드 ~150 ms 미발동 — 가드가 가리키는 본문의 90 ms 는 그룹 실행 비용이고, 같은 자에서 재면 9a75c74 median 86.3 ms, HEAD median 78.1 ms (Premise 1 토글). 종단 값도 별도로 재서 #1335 의 2026-09-05 실측 범위와 일치함을 확인했습니다. 멤버 중앙값 0.52 ms, 상위 2개 합 23.4 ms 가 멤버 시간 58.6 ms 의 40% 로 한 곳을 고쳐 줄이는 구조가 아님 (Task 1 토글)	no ground
Alternative	본문이 지목한 대안 3개 중 옵션 2 는 본문 스스로 not recommended, 옵션 3 의 #713 과 본문이 보류 근거로 든 #1277·#1278 은 전부 CLOSED (Task 3 토글) — 즉 더 싼 경로가 열려 있는 상태가 아님	none
Urgency	본문이 옵션 절을 Options (none urgent) 로 표기, 그 위에 가드까지 달았고 그 가드가 미발동	can wait

Need 가 no ground 이므로 Alternative 가 none 이어도 Proceed 에 닿지
않습니다.

Premises

#	Premise	Source	Result
1	9a75c74 에서 no-op Bash 디스패치 그룹이 ~90 ms	author	CONFIRMED(in-process 재측정 median 86.3 ms)
2	디스패치마다 모듈 수준 정규식 ~188개를 재컴파일	author	CONFIRMED(189 @ 9a75c74, 191 @ HEAD)
3	멤버 55개	author	CONFIRMED(양쪽 커밋 모두 55)
4	그 중 ~60 ms 가 import + 정규식 컴파일	author	CONFIRMED(import 16.0 + 멤버 로드 25.0 = 41.0 / 63.7 ms; re.compile 192회 누적 27 ms)
5	transcript 스캔 멤버 2개가 실사용 지연을 한 자릿수 배 지배	author	UNKNOWN

Premise 1 — 기준선은 두 커밋을 같은 기계에서 나란히 재야 비교가 됩니다

가드가 걸린 대상은 본문 첫 줄의 costs 90 ms in the PreToolUse(Bash) dispatch group — 즉 인터프리터 기동과 셸 래퍼를 제외한 그룹 실행 비용입니다. 그래서
같은 자로 재고, 반복마다 새 프로세스를 띄워 re 캐시가 차갑게 시작하도록 했습니다 —
실제 훅 디스패치가 매번 겪는 조건입니다. 9회 중 best/median.

$ python3 cmp1283.py
9a75c74 (issue)  best   68.6 ms | median   86.3 ms | re.compile 189
HEAD 9738307     best   70.8 ms | median   78.1 ms | re.compile 191

본문의 90 ms 와 재측정 median 86.3 ms 가 일치하는 범위이므로 CONFIRMED 입니다.
비교 대상 커밋은 /tmp/praxis-perf-9a75c74 에 분리 워크트리로 체크아웃해 썼고,
측정 후 git worktree remove 로 제거했습니다.

종단 값(인터프리터 기동 + 셸 래퍼 + 훅이 내부에서 부르는 subprocess 포함)도 따로
쟀습니다. 기계 부하가 두 값을 함께 흔들도록 인터프리터 바닥값과 번갈아 21회씩
돌렸습니다.

$ python3 e2e1283.py
floor     best   17.7 ms | median   19.4 ms | p90   23.2 ms
dispatch  best  141.9 ms | median  169.2 ms | p90  207.1 ms

이 측정은 공유 개발 기계에서 돌았고 부하가 일정하지 않습니다(같은 세션 뒤쪽에서
load average 43 을 기록). 그래서 절대치는 상한으로 읽어야 하고, 번갈아 잰 두 행의
관계만이 부하와 무관합니다. 그 조건에서도 이 값은 #1335 본문이 2026-09-05 에
실측으로 적은 110~210 ms 범위 안에 있어,
종단 쪽에서도 드리프트가 보이지 않습니다. 종단 수치는 가드의 대상이 아니지만(가드는
그룹 비용 90 ms 를 가리킴), 두 자 모두에서 같은 답이 나온다는 교차 확인입니다.

Premise 2 — 정규식 컴파일 횟수는 `re.compile` 을 직접 세서 확인했습니다

프로브가 re.compile 을 카운팅 래퍼로 교체해 디스패치 1회당 호출 수를 셉니다.
Premise 1 토글의 같은 출력 마지막 열이 그 값입니다 — 9a75c74 189회, HEAD 191회.
본문의 188 이 재현되고, HEAD 에서 2 건 늘어난 것은 그 사이 추가된 훅의 몫입니다.

Premise 3 — 멤버 수는 디스패처가 실제로 실행한 횟수로 셉니다

manifest 선언이 아니라 run_one 호출 횟수로 셌습니다. 선언과 실행이 갈릴 수 있어
실행 쪽이 이 주장의 오라클입니다.

$ python3 runmember.py
group total 78.2 ms | member time 58.6 ms over 55

over 55 가 run_one 이 불린 횟수입니다.

Premise 4 — 구성비는 import / 멤버 로드 / 멤버 로직으로 쪼개 쟀습니다

_dispatch.py 자체 import, 멤버 55개의 _load_main 합, 그리고 그룹 전체 시간을
따로 재면 멤버 로직이 잔차로 나옵니다.

$ python3 permember.py
import _dispatch.py itself :   16.0 ms
run_group (55 members)     :   63.7 ms
member load total (55)     :   25.0 ms

import + 멤버 로드 = 41.0 ms / 63.7 ms. 그 안에서 정규식 컴파일이 차지하는 몫은
cProfile 로 분리했습니다 — 192회 누적 27 ms.

$ python3 prof1283.py
         207288 function calls (201593 primitive calls) in 0.123 seconds

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.105    0.105 hooks/_lib/_dispatch.py:866(main)
       55    0.000    0.000    0.085    0.002 hooks/_lib/_dispatch.py:329(run_one)
       55    0.000    0.000    0.051    0.001 hooks/_lib/_dispatch.py:249(_load_main)
      192    0.000    0.000    0.027    0.000 re/__init__.py:287(compile)

위 블록은 18행 중 관련 4행만 발췌했고, 경로의 홈 디렉터리 접두부를 지웠습니다.

본문의 "~60 ms" 와 비율이 맞으므로 CONFIRMED 로 두되, 절대치는 기계가 달라 본문의
값과 1:1 대응하지 않습니다.

Premise 5 — 실사용 지연 지배 주장은 이 리뷰의 오라클 밖입니다

#1277·#1278 은 이미 CLOSED 이므로 두 멤버의 당시 비용은 현재 코드에 없습니다.
"실사용 지연을 한 자릿수 배 지배"를 판정하려면 당시 로스터에서의 실사용 telemetry 가
필요하고, 이 세션은 현재 HEAD 와 9a75c74 두 커밋만 쟀습니다. 따라서 UNKNOWN 이며,
이 행은 Verdict 를 움직이지 않습니다 — Reject 는 Need 축이 단독으로 지탱합니다.

Tasks

#	Task	Result
1	옵션 1 — 무거운 패턴을 functools.lru_cache 접근자 뒤로 옮겨 lazy 컴파일	out of scope
2	옵션 2 — precompiled cache	out of scope
3	옵션 3 — 멤버 수 감소(prune 감사)	already exists

Task 1 — 가드 미발동 구간에서 55개 멤버를 건드리는 변경입니다

아래 분포가 이 판정의 근거입니다. 중앙값 0.52 ms 에 지배적 멤버가
없으므로, lazy 화의 이득은 한 곳이 아니라 55개 멤버에 얇게 퍼진 비용을 55군데에서
긁어내는 형태가 됩니다. 모듈 상수를 접근자 함수 뒤로 옮기는 변경이라 훅 본문 다수의
가독성과, 훅 본문을 패턴 매칭으로 읽는 scripts/hook_channels.py 의 채널 탐지까지
영향 범위에 들어갑니다. 얻는 것은 가드가 발동하지 않은 구간의 수십 ms 입니다.

$ python3 runmember.py
group total 78.2 ms | member time 58.6 ms over 55
    12.3 ms  advisory-nudge/memory-hint
    11.1 ms  advisory-nudge/cwd-relative-exec-advisory
     2.5 ms  advisory-nudge/n1-quantitative-claim-advisory
     1.9 ms  preflight-gate/gh-label-verify
     1.9 ms  advisory-nudge/output-block-falsify-advisory
     1.7 ms  preflight-gate/anchor-comment-gate
  median member: 0.52 ms

Refutation: 한 멤버가 그룹 시간의 과반을 쓰고 있었다면 이 행은 valid 가 됐을
것입니다. Positive control: 같은 계측이 최상위 멤버에 12.3 ms 라는 큰 값을 실제로
찍으므로, "지배적 멤버 없음"이 계측 실패가 아님을 보증합니다. 덧붙여 첫 cProfile 이
cwd-relative-exec-advisory 에 25 ms 를 붙였던 것은 import 비용 합산 때문이고,
run_one 직접 계측에서 11.1 ms 로 내려갑니다 — cProfile 쪽 귀속이 틀렸습니다.

Task 2 — 본문 자신이 권하지 않는 항목입니다

본문 표현 그대로 not available for re without pickling tricks; not recommended.
이 리뷰에서 추가로 판정할 것이 없습니다.

Task 3 — prune 감사는 산출물이 이미 존재하고 이슈도 닫혔습니다

$ wc -c docs/hook-prune-audit.md
   20418 docs/hook-prune-audit.md
$ gh issue view 713 --repo devseunggwan/praxis --json number,state,title --jq '"#\(.number) \(.state) \(.title)"'
#713 CLOSED chore(hooks): evidence-based hook prune audit

문서 머리글은 스스로 Snapshot. Scored against the August 2026 roster (81 hooks, 63 exactly scoreable) 이라고 적고 있어 현재 로스터(55 멤버 실행)와 다릅니다. 즉
"멤버를 더 줄인다"는 이 이슈에서 집행할 수 있는 열린 작업이 아니고, 하려면 현재
로스터로 재측정하는 별도 결정이 필요합니다.

Unverified — 종단 값의 커밋 간 직접 비교 미수행 · `#1277`·`#1278` 당시의 실사용 지연 지배 여부(Premise 5) · 현재 로스터 기준 prune 여력

• 종단 값을 9a75c74 에서도 재서 HEAD 와 직접 비교하지는 않았습니다(비교용 워크트리를
  측정 후 제거함). 다음 행동 없음 — 드리프트 판정은 그룹 비용의 커밋 간 비교로 성립하고,
  종단 쪽은 #1335 의 2026-09-05 실측 범위와의 일치로 교차 확인했습니다.
• Premise 5 는 CLOSED 이슈 당시의 telemetry 가 필요합니다. 다음 행동 없음 — 두 훅은
  이미 고쳐져 현재 코드에 그 비용이 없습니다.
• 현재 로스터(55 멤버)에 prune 여력이 남았는지는 재측정 대상입니다. 다음 행동 없음 —
  새 결정 없이 이 이슈에서 집행할 항목이 아닙니다.

History

rev 1 — 9738307 기준. 최초 게시.

rev 2 — 같은 커밋. rev 1 이 게시한 값 정정. rev 1 은 "이 기계의
python3 -c pass 가 80~110 ms 라 종단 절대치를 가드와 비교할 수 없다"고 적고
종단 실측을 296.4 ms 로 인용했습니다. 둘 다 틀렸습니다 — 인터프리터 바닥값은
best 17.7 ms / median 19.4 ms 이고, 종단은 best 141.9 ms / median 169.2 ms 입니다.
그래서 "비교 불가"라는 근거를 지우고, (a) 가드가 가리키는 대상이 본문의 그룹 비용
90 ms 라는 점을 명시하고 (b) 종단 값을 실측해 #1335 의 2026-09-05 실측 범위
110~210 ms 와 일치함을 교차 확인으로 추가했습니다. Verdict 는 Reject 로
불변이며, 근거는 오히려 두 자에서 각각 확인된 형태로 강화됐습니다.

rev 3 — 같은 커밋. rev 2 가 실은 종단 수치의 측정 조건을 Premise 1 토글에
추가했습니다: 공유 개발 기계이고 같은 세션 뒤쪽에서 load average 43 을 기록했으므로
종단 절대치는 상한으로 읽어야 합니다. 커밋 간 비교(그룹 비용)는 번갈아 측정이라
영향을 받지 않고, Verdict 도 불변입니다.

[devseunggwan]

Review updated — 9738307 rev 2 · rev 1 이 게시한 인터프리터 바닥값(80~110 ms)과 종단 실측(296.4 ms)이 틀려서 정정했습니다(실측 17.7 / 141.9 ms). "종단은 비교 불가"라는 근거를 실측 교차 확인으로 교체했고 Verdict: Reject 는 불변입니다 → #1283 (comment)

[devseunggwan]

Review updated — 9738307 rev 3 · 종단 수치의 측정 조건(공유 기계, 같은 세션 뒤쪽 load average 43)을 Premise 1 토글에 추가했습니다. 절대치는 상한으로 읽어야 하며, 커밋 간 비교와 Verdict: Reject 는 불변입니다 → #1283 (comment)

[devseunggwan]

Review — pre-work

Verdict: Rescope → hold — 이 이슈가 스스로 정한 착수 조건("Suggest deferring unless the baseline drifts past ~150 ms")을 지금 재측정했고, 기준선은 넘지 않았습니다(중앙값 102 ms). Premises/Tasks 표는 생략합니다 — 본문의 Options 는 체크리스트가 아니라 착수 조건 하나에 종속된 후보 목록이라, 그 조건이 미충족인 지금은 판정할 대상이 없습니다.

한 줄 요약: ls -la 한 번에 드는 훅 고정비는 여전히 0.1초 정도이고, 이슈가 직접 적어 둔 손익분기(0.15초)에 아직 닿지 않았습니다.

Axis	Ground	Result
Need	이슈 본문의 착수 조건을 그대로 재측정했습니다. 워밍업 2회를 버린 10회 실행의 중앙값 102 ms, 최소 98, 최대 178 — 기록된 90 ms 와 같은 자릿수이고 150 ms 아래입니다(Evidence 1). 멤버 수도 기록 그대로 55 입니다.	no ground
Alternative	이슈가 적어 둔 옵션 3(docs/hook-prune-audit.md 로 멤버 수를 줄이는 것)이 같은 비용을 더 싸게 줄입니다 — 지연을 만드는 것은 정규식 자체가 아니라 멤버 55개의 exec 이고, 드롭 한 개가 exec 한 개와 그 안의 컴파일 전부를 동시에 없앱니다. 옵션 1(lazy compile)은 55개 파일에 접근자를 심는 편집인데, 그 대가로 줄어드는 것은 이미 예산 안에 있는 값입니다.	better
Urgency	이슈 본문: 실사용 지연은 transcript 를 스캔하는 멤버 두 개(#1277, #1278)가 한 자릿수 배 더 지배합니다. 고정비는 그 뒤입니다.	can wait

Need 가 no ground 이고 Alternative 가 better 라 Proceed 로 갈 길이 없습니다. 제가 이 이슈를 닫지는 않았습니다 — 착수 조건이 살아 있는 관측 기록으로서는 유효하고, 기준선이 드리프트하면 그대로 다시 발동하는 형태이기 때문입니다.

Evidence 1 — 기준선 재측정 (중앙값 102 ms)

호스트가 PreToolUse 에서 부르는 진입점을 그대로 12회 호출하고, 파일시스템 캐시가 더워지는 앞 2회를 버렸습니다. 원장은 scratch 로 격리했습니다(PRAXIS_HOME, PRAXIS_FIRE_TELEMETRY_FILE).

$ python3 - "$S"   # subprocess.run(["bash","hooks/_dispatch.sh","PreToolUse","Bash","claude"]) × 12, 앞 2회 버림
n=10 median=102 ms  min=98  max=178
all: ['103', '125', '178', '131', '99', '101', '98', '101', '103', '100']
$ python3 -c "
import sys; sys.path.insert(0,'hooks/_lib')
import _dispatch
print(len(_dispatch.group_members('PreToolUse','Bash','claude')))"
55

$S 는 세션 scratchpad 아래 perf 디렉터리의 절대 경로를 가린 것입니다. payload 는 tool_input.command = "ls -la" 로, 이슈가 쓴 것과 같은 no-op 명령입니다.

Refutation: 고정비가 드리프트했다면 중앙값이 150 ms 를 넘겨야 합니다. 넘지 않았습니다.
Positive control: 이 측정이 실제로 훅을 돌렸다는 것 — 같은 진입점·같은 payload 가 55개 멤버를 로드한다는 것을 멤버 수 프로브가 보여 줍니다. 디스패처가 즉시 빠져나왔다면 8 ms 대(python3 -c pass)가 나왔을 것이고, 102 ms 는 그 12배입니다.

Method — 이 리뷰가 쓴 오라클

이 이슈 자신의 산출물은 쓰지 않았습니다. 브랜치를 자르지 않았고, 근거는 (a) 이슈 본문이 명시한 착수 조건과 (b) 지금 이 워크트리에서 돌린 실측입니다.

측정의 한계는 적어 둡니다: 단일 호스트의 벽시계 시간이라 경합에 민감합니다(178 ms 이상치가 그 자리입니다). 그래서 평균이 아니라 중앙값으로 읽었고, cProfile 로 구성요소별 재분해는 하지 않았습니다 — 착수 조건이 총 시간 하나로 쓰여 있어서 총 시간만으로 판정이 끝납니다.

[devseunggwan]

Baseline re-measured — still under the deferral threshold

이 이슈는 "baseline 이 ~150 ms 를 넘으면 그때 손대라"는 조건부 보류입니다. 그 조건이 충족됐는지만 재 봤습니다. 결론부터: 아직 아닙니다.

읽는 법 먼저 — Bash dispatch 그룹의 멤버 수가 늘지 않았습니다. 그 사이 훅이 여럿 추가됐지만 전부 다른 이벤트로 갔기 때문에, 이 그룹이 매 호출마다 exec 하는 impl.py 개수는 9a75c74 때와 똑같이 55개입니다.

$ python3 -c 'import json;h=json.load(open("hooks/manifest.json"))["hooks"];print(sum(1 for x in h if x.get("event")=="PreToolUse" and x.get("matcher")=="Bash"))'
55

측정은 실제 dispatcher 에 payload 를 넣어 wall-clock 을 재는 방식이고, HOME·PRAXIS_HOME·PRAXIS_STATE_DIR·PRAXIS_FIRE_TELEMETRY_FILE 를 scratch 트리로 돌려 운영 상태를 건드리지 않습니다.

기계가 다르면 절대값이 다르다는 점이 중요합니다. 이슈에 적힌 90 ms 와 오늘 값을 직접 빼면 안 됩니다 — 같은 커밋(9a75c74)을 오늘 이 기계에서 재면 107 ms 이기 때문입니다. 그래서 옛 커밋 트리와 현재 main 을 번갈아 돌려 같은 부하 구간에서 비교했습니다.

$ python3 bench-ab.py <9a75c74 트리> <main 워크트리> 15
old9a75                  n=15 min= 101.0 median= 107.0 max= 115.1
praxis                   n=15 min= 105.8 median= 113.3 max= 125.3

읽는 법: 9a75c74 이후 누적 드리프트는 +6.3 ms (약 6%) 이고, 멤버 수가 그대로이므로 늘어난 몫은 공용 _lib import 와 기존 멤버들의 모듈 레벨 regex 쪽입니다. 이 이슈가 지목한 구조 그대로입니다.

측정	median
9a75c74 트리 (오늘, 이 기계)	107.0 ms
main a39e227	113.3 ms
보류 해제 기준	~150 ms

멤버 하나 추가의 한계 비용도 같이 재 봤습니다 — 56 멤버 브랜치와 55 멤버 main 을 번갈아 돌리면 노이즈보다 작습니다(median 118.6 vs 120.8, 56 멤버 쪽이 오히려 낮음). 즉 지금 구간에서는 "멤버 하나 = 눈에 보이는 지연"이 아닙니다.

Verdict: 보류 유지. 기준선이 조건에 닿지 않았고, 여기서 옵션 1(lazy compile)을 지금 하면 측정으로 정당화되지 않는 변경이 됩니다. 부하가 높은 순간에는 개별 샘플이 150 ms 를 찍으므로(위 max 와 별도로, 다른 구간에서 151.7 ms 관측), 다음에 다시 잴 때는 median 을 기준으로 보시면 됩니다.

확인 범위: 이 기계 1대, ls -la payload 1종, 라운드 15회 교차 2세트. 다른 payload(트랜스크립트를 읽는 멤버가 깨어나는 명령)는 재지 않았습니다 — 그쪽이 실사용 지연을 지배한다는 이슈 본문의 기술은 이번 측정으로 확인도 반증도 되지 않았습니다.

[devseunggwan]

Baseline re-measured after 7.19.0 — still under the deferral threshold

The Bash PreToolUse group grew from 55 to 61 members since the last check, so the deferral condition ("~150 ms") was re-measured. It still holds: median 98.5 ms on main (09576ce4).

Member count on each tree (both extracted with git archive):

9a75c74 rc=0,0
bash hooks: 55
09576ce4 rc=0,0
bash hooks: 61

Latency of one _dispatch.sh PreToolUse Bash claude call for an ls -la payload, 15 runs per tree after one warm-up round, the two trees interleaved so host drift hits both alike; praxis state, home and fire ledger redirected to a temp dir. This is a different harness from the earlier bench-ab.py numbers, so compare the two rows with each other, not with the 107/113 ms above. The scratch path is replaced with <scratchpad>.

$ python3 "$S/bench1283.py" "old9a75=$S/b1283-9a75c74" "main=$S/b1283-09576ce4" 15   # S=<scratchpad>
old9a75    n=15 min=   86.8 median=   93.8 max=  123.6
main       n=15 min=   93.4 median=   98.5 max=  128.7

Six more members cost about 5 ms at the median. Deferral stands.