morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4415] [Perf][Exploration] Investigate scoped JavaScript preparation and sealing costs on real Joplin #1755

New issue

Open

opened 2026-10-16 21:09:51 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-16 21:09:51 +00:00

Owner

Originally created by @N0zoM1z0 on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4415

Before submitting

I searched related issues and open PRs; #2498 / #2891 target a different member-mutation workload, #3538 / #3550 target parent-budget remediation, and #3671 concerns projection capacity.
I understand the contribution scope; this is a read-only performance investigation, not approval for a new execution capability.
This report contains no credentials or private target samples.

Area

Evidence, artifacts, or reconstruction

Current limitation

At main d72d856f58d4747c5eb4307426e80d20934e017c, a real Joplin 3.7.21 ASAR workflow selects only ElectronAppWrapper.js (39,972 bytes) and package.json, then retrieves one BrowserWindow fact. It still takes 45.102 s to the first answer (preparation 40.531 s), 44.669897 process-family CPU s and 1,552,072,704 bytes peak cgroup memory. The existing fact view itself takes 120.8 ms initially and 21–24 ms on two same-session repeats. Those repeats are not cold analysis trials.

This is an observed cost, not an established regression. Source selection limits source analysis; the enclosing artifact inventory and complete Evidence remain part of the current contract. A smaller requested answer alone does not authorize omitting that evidence.

Use cases

Repeated static analysis of real Electron apps with a narrow analyst question, while retaining full provenance/coverage and CLI/MCP parity.

Desired outcome and success criteria

Locate and reduce duplicated work at its owning boundary when a measured equivalent complete workflow justifies the change. Preserve identical facts, identity, full Evidence and unknown/partial semantics; preserve cancellation, JSON depth validation and ownership. Compare both run orders, cold-process and within-session behavior, projected whole-task tokens, elapsed time, CPU and process-family memory. Do not introduce a cache or new selector without an observed need and explicit validity/lifetime rules. No production change is proposed yet.

Expected interaction with targets

Read existing files or captured data. No Joplin execution, attachment or instrumentation.

Verification available so far

I have a prototype or observed results.

Verification details

Official Joplin 3.7.21 ASAR: 233,575,014 bytes, SHA256 767df409b18effe60421fbefcca873de237c7e813eac744ecdeebbc5e825a33a. The complete CLI/MCP fact answer, raw semantic fingerprint and Evidence parity match the #4400 verification record after merge. Structured whole-task BPE projection is 13,432 using the pinned verifier/tiktoken 0.12.0; this is not billed usage or live-agent context.

A separate parent-only Node CPU-profile CLI diagnostic completed in 38.147 s / 37.736337 family CPU s / 1,010,319,360 peak cgroup bytes. Its 37.682 s sampling weight includes idle/native frames: graph construction/sealing, canonical hashing, input reads and GC all contribute. The analyzer worker is not profiled; these weights are neither exact phase CPU accounting nor an equivalent MCP timing comparison. Do not add overlapping inclusive rows. Both workflows used Node24.18.0, one CPU, 8GiB hard/6GiB early limits, no observed OOM and verified owned-payload cleanup. Build/OS caches are uncontrolled and input hashing warms file cache.

Reproduce the public CLI diagnostic after building the pinned main, under the existing resource observer:

node --cpu-prof --cpu-prof-dir=/absolute/tmp/profile-dir scripts/rea.mjs \
  analyze-javascript-application /absolute/path/to/app.asar \
  --source-path ElectronAppWrapper.js --source-path package.json --format json >/dev/null

A compact sampling summarizer and receipts are being retained on an exploration branch; no PR will be opened for this investigation alone. Regenerable app binaries, large Evidence exports and raw CPU profiles are not archived.

Alternatives considered

The existing retained-fact view already bounds the answer; it does not remove preparation. Reusing authenticated immutable roots is promising, but an immutable snapshot alone does not prove the full JSON depth/proxy contract: validation cannot simply be removed. The current profile does not justify speculative persistent caching.

References

Part of #4027; follows #4366 / #4400. Popup #3536 remains separate: its real Joplin helper passes webContents recursively, so a method name alone must not invent a proven opener.

Exploration checkpoint

The compact receipts and a sampling summarizer are preserved locally on perf/javascript-analysis-cost-20261016 in /home/yann/yann/rea-javascript-analysis-cost-20261016; no exploration PR is opened. Summarizer replay and independent sample-count comparison pass on the actual Node profile. It preserves the one observed -2us delta rather than clamping it; rows rank by sample counts, with signed delta weights explicitly labelled. There is no production code change or claimed optimization gain. The immutable owner still requires independent JSON depth/proxy validation, so that check has not been bypassed. Raw profiles and regenerable large outputs are removed after compact verification.

Originally created by @N0zoM1z0 on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4415 ### Before submitting - [x] I searched related issues and open PRs; #2498 / #2891 target a different member-mutation workload, #3538 / #3550 target parent-budget remediation, and #3671 concerns projection capacity. - [x] I understand the contribution scope; this is a read-only performance investigation, not approval for a new execution capability. - [x] This report contains no credentials or private target samples. ### Area Evidence, artifacts, or reconstruction ### Current limitation At main `d72d856f58d4747c5eb4307426e80d20934e017c`, a real Joplin 3.7.21 ASAR workflow selects only `ElectronAppWrapper.js` (39,972 bytes) and `package.json`, then retrieves one BrowserWindow fact. It still takes 45.102 s to the first answer (preparation 40.531 s), 44.669897 process-family CPU s and 1,552,072,704 bytes peak cgroup memory. The existing fact view itself takes 120.8 ms initially and 21–24 ms on two same-session repeats. Those repeats are not cold analysis trials. This is an observed cost, not an established regression. Source selection limits source analysis; the enclosing artifact inventory and complete Evidence remain part of the current contract. A smaller requested answer alone does not authorize omitting that evidence. ### Use cases Repeated static analysis of real Electron apps with a narrow analyst question, while retaining full provenance/coverage and CLI/MCP parity. ### Desired outcome and success criteria Locate and reduce duplicated work at its owning boundary when a measured equivalent complete workflow justifies the change. Preserve identical facts, identity, full Evidence and unknown/partial semantics; preserve cancellation, JSON depth validation and ownership. Compare both run orders, cold-process and within-session behavior, projected whole-task tokens, elapsed time, CPU and process-family memory. Do not introduce a cache or new selector without an observed need and explicit validity/lifetime rules. No production change is proposed yet. ### Expected interaction with targets Read existing files or captured data. No Joplin execution, attachment or instrumentation. ### Verification available so far I have a prototype or observed results. ### Verification details Official Joplin 3.7.21 ASAR: 233,575,014 bytes, SHA256 `767df409b18effe60421fbefcca873de237c7e813eac744ecdeebbc5e825a33a`. The complete CLI/MCP fact answer, raw semantic fingerprint and Evidence parity match the #4400 verification record after merge. Structured whole-task BPE projection is 13,432 using the pinned verifier/tiktoken 0.12.0; this is not billed usage or live-agent context. A separate parent-only Node CPU-profile CLI diagnostic completed in 38.147 s / 37.736337 family CPU s / 1,010,319,360 peak cgroup bytes. Its 37.682 s sampling weight includes idle/native frames: graph construction/sealing, canonical hashing, input reads and GC all contribute. The analyzer worker is not profiled; these weights are neither exact phase CPU accounting nor an equivalent MCP timing comparison. Do not add overlapping inclusive rows. Both workflows used Node24.18.0, one CPU, 8GiB hard/6GiB early limits, no observed OOM and verified owned-payload cleanup. Build/OS caches are uncontrolled and input hashing warms file cache. Reproduce the public CLI diagnostic after building the pinned main, under the existing resource observer: ```sh node --cpu-prof --cpu-prof-dir=/absolute/tmp/profile-dir scripts/rea.mjs \ analyze-javascript-application /absolute/path/to/app.asar \ --source-path ElectronAppWrapper.js --source-path package.json --format json >/dev/null ``` A compact sampling summarizer and receipts are being retained on an exploration branch; no PR will be opened for this investigation alone. Regenerable app binaries, large Evidence exports and raw CPU profiles are not archived. ### Alternatives considered The existing retained-fact view already bounds the answer; it does not remove preparation. Reusing authenticated immutable roots is promising, but an immutable snapshot alone does not prove the full JSON depth/proxy contract: validation cannot simply be removed. The current profile does not justify speculative persistent caching. ### References Part of #4027; follows #4366 / #4400. Popup #3536 remains separate: its real Joplin helper passes webContents recursively, so a method name alone must not invent a proven opener. ### Exploration checkpoint The compact receipts and a sampling summarizer are preserved locally on `perf/javascript-analysis-cost-20261016` in `/home/yann/yann/rea-javascript-analysis-cost-20261016`; no exploration PR is opened. Summarizer replay and independent sample-count comparison pass on the actual Node profile. It preserves the one observed -2us delta rather than clamping it; rows rank by sample counts, with signed delta weights explicitly labelled. There is no production code change or claimed optimization gain. The immutable owner still requires independent JSON depth/proxy validation, so that check has not been bypassed. Raw profiles and regenerable large outputs are removed after compact verification.

bsakaguchi commented

2026-10-16 21:09:53 +00:00

Author

Owner

@Antruly commented on GitHub (Oct 16, 2026):

I read the preparation path behind this report rather than reproducing it, so everything below is source-derived from main @ d72d856f — the same revision this issue measured — and I have not run the Joplin workflow myself. Nothing here is a measurement or a proposed production change; it is what the code says about where the cost is reachable from, plus two things I would check next.

1. The inventory pass reads and hashes every entry before the caller's selection is consulted

reconstructJavaScriptArtifact builds the full snapshot first and only then passes source_paths in:

src/application/javascript/JavaScriptArtifactReconstruction.ts:92-96 — scanCanonicalArtifactInventoryInScope(path, { resourceScope: scope, signal, integrity: … }). source_paths is not part of this call.
src/application/javascript/JavaScriptArtifactReconstruction.ts:120-126 — readJavaScriptArtifactFiles(reader, snapshot, scope, signal, input.source_paths). Selection is applied to an already-complete snapshot.
src/artifacts/inventory/scanReader.ts:288-293 — digestArtifactEntry opens and hashReadables every file/slice entry unconditionally; :296-316 shows the integrity policy only decides what happens after a mismatch (fail throws, record-and-continue records a contradiction). The hash itself is not conditional.

So --source-path bounds source-text acquisition and analysis, not the inventory pass: src/artifacts/javascript/JavaScriptArtifactFiles.ts:163-173 reports unselected files as outside-analysis-scope while the files/containers listing stays complete.

That is consistent with this issue's headline numbers: a request scoped to ElectronAppWrapper.js and package.json still pays for the whole 233 MB archive before the first answer, and the same pass is why the documented scoped workflow still takes 143 s on the #3538 target.

The only size-based refusals on this path are hard caps thrown during that pass — src/artifacts/AsarHeader.ts:7 (16 MiB header decode budget) and src/artifacts/AsarListing.ts:8 (64 MiB expanded listing budget) — not an estimate of what the run will cost.

2. The generic memory remediation names a mechanism this path does not implement

src/domain/analysisErrorPresentation.ts:71 still ends with "…Retry with sufficient memory or a smaller artifact; REA retains tighter inherited limits."

For JavaScript/Electron analysis there is no inherited limit to retain. The worker heap is selected explicitly and ambient heap flags are removed:

src/javascript/analysis/JavaScriptAnalysisWorker.ts:466 — --max-old-space-size=${String(this.limits.heapMb)}
src/javascript/analysis/JavaScriptAnalysisWorker.ts:462 — delete environment.NODE_OPTIONS
range 128–16384 at :119-129; defaults heapMb: 1024, timeoutMs: 300_000 at src/domain/javascript/javascriptAnalysisResourceControls.ts:6-11; CLI wiring src/cli/electronCommands.ts:281-289

The only code that reads or clamps inherited kernel limits is src/process/LinuxResourceLimits.ts (:42-65 clamp, :68-105 read), and its consumers are the capture/analysis producers — src/captures/TsharkCaptureProvider.ts:13-15, src/pcap/PcapProvider.ts:50, src/signals/SigrokRecordingProvider.ts:12-14, src/process/ArtifactAnalysisResources.ts:22-24. Nothing under src/javascript/ reads it. The remaining memory reads in this path are the process's own V8 heap (JavaScriptAnalysisWorker.ts:146-147, :575-576, :677-678; JavaScriptAnalysisWorkerServer.ts:67,84-85).

So for this failure the actionable lever is the heap the caller or the default chose, and the numbers are usually already in reported_limits (worker_old_space_mb, parent_result_budget_bytes). The parent side is a heap-derived heuristic, not a measured need — JavaScriptAnalysisWorker.ts:143-151:

this.#resultBudgetBytes = Math.max(0, Math.floor(
  (getHeapStatistics().heap_size_limit - process.memoryUsage().heapUsed
    - 24 * JAVASCRIPT_ANALYSIS_TRANSFER_RECORD_BYTES) / 2,
));

re-evaluated at :575-576 and :677-678. That shape — budget derived from the current heap rather than from what the work needs — is also a plausible source of the contradictory application_projection_required_bytes vs parent_result_budget_bytes figures in #3671; I have not verified that link.

3. What I would check next

Not a change proposal, just the measurement the report itself says is missing ("The analyzer worker is not profiled"):

Split one complete workflow into phases with receipts: (a) inventory enumerate + hash, (b) source-text acquisition, (c) worker analysis, (d) graph sealing and projection. Point 1 gives the reason — no caller-side selection can reduce (a), so any "duplicated work" claim needs (a) separated from (b).
If (a) dominates, decide whether the same validated snapshot can be reused for a repeated answer over an unchanged artifact (cache key = artifact digest + integrity policy), with an explicit lifetime. Your issue text rules out speculative caching, which is why I would only look at this after (a) is separately measured.

Disclosure

#3550 is mine and touched the sibling branch of this same remediation — it made the parent_result_budget_exhausted case stop advising more worker memory and stated that the limit belongs to the parent result budget. Point 2 is the adjacent generic branch, which it did not change.

@Antruly commented on GitHub (Oct 16, 2026): I read the preparation path behind this report rather than reproducing it, so everything below is **source-derived from `main` @ `d72d856f`** — the same revision this issue measured — and I have not run the Joplin workflow myself. Nothing here is a measurement or a proposed production change; it is what the code says about where the cost is reachable from, plus two things I would check next. ### 1. The inventory pass reads and hashes every entry *before* the caller's selection is consulted `reconstructJavaScriptArtifact` builds the full snapshot first and only then passes `source_paths` in: - `src/application/javascript/JavaScriptArtifactReconstruction.ts:92-96` — `scanCanonicalArtifactInventoryInScope(path, { resourceScope: scope, signal, integrity: … })`. `source_paths` is not part of this call. - `src/application/javascript/JavaScriptArtifactReconstruction.ts:120-126` — `readJavaScriptArtifactFiles(reader, snapshot, scope, signal, input.source_paths)`. Selection is applied to an already-complete snapshot. - `src/artifacts/inventory/scanReader.ts:288-293` — `digestArtifactEntry` opens and `hashReadable`s **every** `file`/`slice` entry unconditionally; `:296-316` shows the integrity policy only decides what happens *after* a mismatch (`fail` throws, `record-and-continue` records a contradiction). The hash itself is not conditional. So `--source-path` bounds source-text acquisition and analysis, not the inventory pass: `src/artifacts/javascript/JavaScriptArtifactFiles.ts:163-173` reports unselected files as `outside-analysis-scope` while the `files`/`containers` listing stays complete. That is consistent with this issue's headline numbers: a request scoped to `ElectronAppWrapper.js` and `package.json` still pays for the whole 233 MB archive before the first answer, and the same pass is why the documented scoped workflow still takes 143 s on the #3538 target. The only size-based refusals on this path are hard caps thrown *during* that pass — `src/artifacts/AsarHeader.ts:7` (16 MiB header decode budget) and `src/artifacts/AsarListing.ts:8` (64 MiB expanded listing budget) — not an estimate of what the run will cost. ### 2. The generic memory remediation names a mechanism this path does not implement `src/domain/analysisErrorPresentation.ts:71` still ends with "…Retry with sufficient memory or a smaller artifact; **REA retains tighter inherited limits**." For JavaScript/Electron analysis there is no inherited limit to retain. The worker heap is selected explicitly and ambient heap flags are removed: - `src/javascript/analysis/JavaScriptAnalysisWorker.ts:466` — `--max-old-space-size=${String(this.limits.heapMb)}` - `src/javascript/analysis/JavaScriptAnalysisWorker.ts:462` — `delete environment.NODE_OPTIONS` - range `128`–`16384` at `:119-129`; defaults `heapMb: 1024`, `timeoutMs: 300_000` at `src/domain/javascript/javascriptAnalysisResourceControls.ts:6-11`; CLI wiring `src/cli/electronCommands.ts:281-289` The only code that reads or clamps inherited kernel limits is `src/process/LinuxResourceLimits.ts` (`:42-65` clamp, `:68-105` read), and its consumers are the capture/analysis producers — `src/captures/TsharkCaptureProvider.ts:13-15`, `src/pcap/PcapProvider.ts:50`, `src/signals/SigrokRecordingProvider.ts:12-14`, `src/process/ArtifactAnalysisResources.ts:22-24`. Nothing under `src/javascript/` reads it. The remaining memory reads in this path are the process's own V8 heap (`JavaScriptAnalysisWorker.ts:146-147`, `:575-576`, `:677-678`; `JavaScriptAnalysisWorkerServer.ts:67,84-85`). So for this failure the actionable lever is the heap the caller or the default chose, and the numbers are usually already in `reported_limits` (`worker_old_space_mb`, `parent_result_budget_bytes`). The parent side is a heap-derived heuristic, not a measured need — `JavaScriptAnalysisWorker.ts:143-151`: ``` this.#resultBudgetBytes = Math.max(0, Math.floor( (getHeapStatistics().heap_size_limit - process.memoryUsage().heapUsed - 24 * JAVASCRIPT_ANALYSIS_TRANSFER_RECORD_BYTES) / 2, )); ``` re-evaluated at `:575-576` and `:677-678`. That shape — budget derived from the *current* heap rather than from what the work needs — is also a plausible source of the contradictory `application_projection_required_bytes` vs `parent_result_budget_bytes` figures in #3671; I have not verified that link. ### 3. What I would check next Not a change proposal, just the measurement the report itself says is missing ("The analyzer worker is not profiled"): - Split one complete workflow into phases with receipts: (a) inventory enumerate + hash, (b) source-text acquisition, (c) worker analysis, (d) graph sealing and projection. Point 1 gives the reason — no caller-side selection can reduce (a), so any "duplicated work" claim needs (a) separated from (b). - If (a) dominates, decide whether the same validated snapshot can be reused for a repeated answer over an unchanged artifact (cache key = artifact digest + integrity policy), with an explicit lifetime. Your issue text rules out speculative caching, which is why I would only look at this after (a) is separately measured. ### Disclosure #3550 is mine and touched the sibling branch of this same remediation — it made the `parent_result_budget_exhausted` case stop advising more worker memory and stated that the limit belongs to the parent result budget. Point 2 is the adjacent generic branch, which it did not change.

bsakaguchi commented

2026-10-17 21:03:23 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 16, 2026):

Additional single-call preflight observation, not a speedup or completed analyst-task benchmark:

Official VSCodium 1.140.06880 Linux x64 archive (212,538,680 B), SHA-256 61223b74f9e40834117311ec4177cb386d09b84c1aae4f9e674c96580569cef3, verified against the official GitHub release asset digest. Analyzed the full extracted resources/app with exact --source-path out/main.js; that selected entry is 100,087 B, SHA-256 0762b59a63f4ed640905bfa3c5bebf78d19508b06a2d3253d374ab3d111a6cad.

Observed source selection reports the exact requested path and 4,539 unselected files. The full CLI output, including progress/Evidence and the resource receipt, is 87,316,011 B; inventory remains in the graph. Wall 33.320 s, payload-exit CPU 31.338796 s, cgroup peak 1,101,549,568 B, with verified complete-family observation at payload exit (observer still alive). This includes the call's startup/inventory/analysis/serialization, not later manual caller discovery or fuse inspection. No agent/billed token measurement or before/after comparison was performed.

Invocation: node scripts/rea.mjs analyze-javascript-application APP --source-path out/main.js --max-heap-mb 1536 --analysis-timeout-ms 120000 --format json. Existing compiled static runtime built at 709b5cbd was reused from the #4605 worktree; not a rebuilt current-main acceptance run. One CPU, 8 GiB hard/6 GiB early, no swap, 192 tasks, parent V8 heap 2048 MiB. Warm filesystem/toolchain, single run. Peak includes file cache, not RSS.

This strengthens the case for measuring preparation/inventory, sealing and serialization separately from the selected source analysis, before deciding what to cache or project. The entry itself has no trashItem; later source-only inspection locates the real callers in out/mainImpl.js, so this one call does not complete that lookup task. No finding that current compact MCP replies have the same cost is claimed. Regenerable application and large raw output stay temporary; compact metrics/source identity are recorded locally for the follow-up.

@N0zoM1z0 commented on GitHub (Oct 16, 2026): Additional **single-call preflight observation**, not a speedup or completed analyst-task benchmark: Official VSCodium 1.140.06880 Linux x64 archive (212,538,680 B), SHA-256 `61223b74f9e40834117311ec4177cb386d09b84c1aae4f9e674c96580569cef3`, verified against the official GitHub release asset digest. Analyzed the full extracted `resources/app` with exact `--source-path out/main.js`; that selected entry is 100,087 B, SHA-256 `0762b59a63f4ed640905bfa3c5bebf78d19508b06a2d3253d374ab3d111a6cad`. Observed source selection reports the exact requested path and **4,539 unselected files**. The full CLI output, including progress/Evidence and the resource receipt, is **87,316,011 B**; inventory remains in the graph. Wall **33.320 s**, payload-exit CPU **31.338796 s**, cgroup peak **1,101,549,568 B**, with verified complete-family observation at payload exit (observer still alive). This includes the call's startup/inventory/analysis/serialization, not later manual caller discovery or fuse inspection. No agent/billed token measurement or before/after comparison was performed. Invocation: `node scripts/rea.mjs analyze-javascript-application APP --source-path out/main.js --max-heap-mb 1536 --analysis-timeout-ms 120000 --format json`. Existing compiled static runtime built at `709b5cbd` was reused from the #4605 worktree; **not a rebuilt current-main acceptance run**. One CPU, 8 GiB hard/6 GiB early, no swap, 192 tasks, parent V8 heap 2048 MiB. Warm filesystem/toolchain, single run. Peak includes file cache, not RSS. This strengthens the case for measuring preparation/inventory, sealing and serialization separately from the selected source analysis, before deciding what to cache or project. The entry itself has no `trashItem`; later source-only inspection locates the real callers in `out/mainImpl.js`, so this one call does not complete that lookup task. No finding that current compact MCP replies have the same cost is claimed. Regenerable application and large raw output stay temporary; compact metrics/source identity are recorded locally for the follow-up.

bsakaguchi commented

2026-10-31 00:32:35 +00:00

Author

Owner

@SII-YDD commented on GitHub (Oct 18, 2026):

Independent current-main selected-source CLI preflight, not an optimization or completed multi-call analyst-task benchmark.

Pinned main 52b73ee857029a3ab8f5c6eeef233b295951a46c, Node24.18.0/npm11.16.0, Linux arm64; official VSCodium1.140.06880 asset SHA256 61223b74f9e40834117311ec4177cb386d09b84c1aae4f9e674c96580569cef3 (212,538,680B), checked against the release API digest. Only resources/app was extracted; the downloaded app was not executed. The command was:

node --max-old-space-size=2048 scripts/rea.mjs analyze-javascript-application /artifact \
  --source-path out/main.js --max-heap-mb 1536 --analysis-timeout-ms 120000 --format json

Two fresh-process/container repeats with uncontrolled/warm OS caches, one CPU, 6GiB hard/no swap, 4,500MiB early memory guard, 192 tasks, UID1000, read-only runtime/input, no network or credentials:

	Repeat1	Repeat2
Wall seconds	16.579	16.664
Waited payload-family CPU seconds	15.521	15.715
Cgroup peak bytes, including file cache/observer	1387429888	1388781568
Raw stdout bytes	87166565	87166565

Both payloads exited0 without guard stops. Exact selection was retained: one parsed file/100,087 text bytes, 4,539 unselected files, 10,705 graph nodes/11,926 edges. out/main.js source SHA256 is 0762b59a63f4ed640905bfa3c5bebf78d19508b06a2d3253d374ab3d111a6cad. All three runs including the separate parent-only profile have identical sorted-key compact normalized-result SHA256 aef44c7824c26c609fb081b691d38d130f8738bf5d5a5172a20d9d5672b21ea6. Coverage remains partial, untruncated, no limits, with selection omissions retained; this does not prove whole-app completeness.

Elapsed progress-boundary intervals, rather than exact phase CPU accounting, were approximately:

Startup to first analysis progress: 0.67–0.70s.
First progress to read_javascript_artifacts (includes admission/inventory): 4.01–4.02s.
That marker to source processing: 3.04–3.09s.
Source processing to application-graph construction: 3.24–3.34s.
Application graph construction/sealing to semantic construction: 2.04–2.08s.
Semantic construction/sealing to result validation: 1.78s.
Remaining validation/Evidence/output/exit: 1.62–1.79s.

Source-derived explanation for the second acquisition cost: JavaScriptArtifactFiles.ts:readText calls verifyEntryBytes even for outside-analysis-scope entries. This preserves the inventory/acquisition byte identity contract; it is not evidence that the check can be removed. The progress intervals include adjacent owner work and scheduling, and should not be renamed pure hashing or parsing time.

The separate parent CPU diagnostic contains7,030 samples (signed delta weight16.786s, including idle/native/GC). Canonical hashing, JSON validation/freezing, graph sealing and output appear among self frames; worker CPU is not profiled. No token count, improvement ratio, complete analyst-task comparison, or cache/scope proposal is claimed. A preliminary container-copy run contaminated its peak with dependency preparation and is excluded from the runtime figures above. Compact receipts/progress/sample summaries are retained locally. AI-assisted investigation; no production change or PR.

@SII-YDD commented on GitHub (Oct 18, 2026): Independent **current-main selected-source CLI preflight**, not an optimization or completed multi-call analyst-task benchmark. Pinned main `52b73ee857029a3ab8f5c6eeef233b295951a46c`, Node24.18.0/npm11.16.0, Linux arm64; official VSCodium1.140.06880 asset SHA256 `61223b74f9e40834117311ec4177cb386d09b84c1aae4f9e674c96580569cef3` (212,538,680B), checked against the release API digest. Only `resources/app` was extracted; the downloaded app was not executed. The command was: ```sh node --max-old-space-size=2048 scripts/rea.mjs analyze-javascript-application /artifact \ --source-path out/main.js --max-heap-mb 1536 --analysis-timeout-ms 120000 --format json ``` Two fresh-process/container repeats with uncontrolled/warm OS caches, one CPU, 6GiB hard/no swap, 4,500MiB early memory guard, 192 tasks, UID1000, read-only runtime/input, no network or credentials: | | Repeat1 | Repeat2 | | --- | ---: | ---: | | Wall seconds | 16.579 | 16.664 | | Waited payload-family CPU seconds | 15.521 | 15.715 | | Cgroup peak bytes, including file cache/observer | 1387429888 | 1388781568 | | Raw stdout bytes | 87166565 | 87166565 | Both payloads exited0 without guard stops. Exact selection was retained: one parsed file/100,087 text bytes, 4,539 unselected files, 10,705 graph nodes/11,926 edges. `out/main.js` source SHA256 is `0762b59a63f4ed640905bfa3c5bebf78d19508b06a2d3253d374ab3d111a6cad`. All three runs including the separate parent-only profile have identical sorted-key compact normalized-result SHA256 `aef44c7824c26c609fb081b691d38d130f8738bf5d5a5172a20d9d5672b21ea6`. Coverage remains partial, untruncated, no limits, with selection omissions retained; this does not prove whole-app completeness. Elapsed **progress-boundary intervals**, rather than exact phase CPU accounting, were approximately: - Startup to first analysis progress: 0.67–0.70s. - First progress to `read_javascript_artifacts` (includes admission/inventory): 4.01–4.02s. - That marker to source processing: 3.04–3.09s. - Source processing to application-graph construction: 3.24–3.34s. - Application graph construction/sealing to semantic construction: 2.04–2.08s. - Semantic construction/sealing to result validation: 1.78s. - Remaining validation/Evidence/output/exit: 1.62–1.79s. Source-derived explanation for the second acquisition cost: `JavaScriptArtifactFiles.ts:readText` calls `verifyEntryBytes` even for `outside-analysis-scope` entries. This preserves the inventory/acquisition byte identity contract; it is not evidence that the check can be removed. The progress intervals include adjacent owner work and scheduling, and should not be renamed pure hashing or parsing time. The separate parent CPU diagnostic contains7,030 samples (signed delta weight16.786s, including idle/native/GC). Canonical hashing, JSON validation/freezing, graph sealing and output appear among self frames; worker CPU is not profiled. No token count, improvement ratio, complete analyst-task comparison, or cache/scope proposal is claimed. A preliminary container-copy run contaminated its peak with dependency preparation and is excluded from the runtime figures above. Compact receipts/progress/sample summaries are retained locally. AI-assisted investigation; no production change or PR.

bsakaguchi referenced this issue

2026-10-31 00:55:09 +00:00

[PR #1755] [MERGED] fix(mcp): cancel evidence imports before session mutation #4797

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1755

No description provided.

Rows
Columns