Skip to content

chore: verify wasmjs-e2e CI job - #261

Open
tstapler wants to merge 1 commit into
mainfrom
ci/verify-wasmjs-e2e
Open

chore: verify wasmjs-e2e CI job#261
tstapler wants to merge 1 commit into
mainfrom
ci/verify-wasmjs-e2e

Conversation

@tstapler

Copy link
Copy Markdown
Owner

Summary

  • Empty-commit PR to exercise the new wasmjs-e2e job in .github/workflows/ci.yml on actual GitHub Actions infra (Linux runner), not just local macOS dry-runs.
  • Opened non-draft since the job is gated on github.event.pull_request.draft == false.

Test plan

  • Wasm/JS E2E check passes on this PR
  • Close/delete this PR + branch once confirmed (no real change to ship)

🤖 Generated with Claude Code

Empty commit to open a PR that exercises the new wasmjs-e2e job
(.github/workflows/ci.yml) end to end on GitHub Actions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

JVM Load Benchmark (Desktop)

Synthetic in-memory benchmark measuring load performance for the desktop (JVM) app.
Comparing 210e4f39 (this PR) vs 210e4f39 (baseline)
Graph config: xlarge — 230 pages

Metric This PR Baseline Delta
Phase 1 TTI ↓ 1ms 1ms 0 (0%)
Phase 2 background ↓ 0ms 0ms 0 (0%)
Phase 3 index ↓ 1ms 1ms 0 (0%)
Total ↓ 2ms 2ms 0 (0%)
Write p95 (baseline) ↓ 17ms 17ms 0 (0%)
Write p95 (under load) ↓ n/a n/a
Jank factor ↓ n/a n/a
↓ lower is better
Flamegraphs (this PR) **Allocation** — object allocation pressure (JDBC/SQLite churn)

Alloc flamegraph not available

CPU — method-level hotspots by on-CPU time

CPU flamegraph not available

Top allocation hotspots (this PR) `35.5%` byte[]_[k] `7.7%` java.lang.String_[k] `7.3%` int[]_[k] `5.4%` java.util.LinkedHashMap$Entry_[k] `4%` java.lang.Object[]_[k]
Top CPU hotspots (this PR) `96.4%` /usr/lib/x86_64-linux-gnu/libc.so.6 `1.3%` clock_nanosleep `0.9%` /tmp/sqlite-3.51.3.0-1a4da2a4-f458-4916-a2cf-ab66d0ea3594-libsqlitejdbc.so `0.3%` __libc_pwrite `0.2%` fsync

@github-actions

Copy link
Copy Markdown
Contributor

Android Load Benchmark

Instrumented benchmark on an API 30 x86_64 emulator — 500-page synthetic graph.

Comparing e9245c86 (this PR) vs 210e4f39 (baseline)
Device: API 30 x86_64 emulator — 530 pages loaded

Graph Load

Metric This PR Baseline Delta
Phase 1 TTI ↓ 30ms 35ms -5ms (-14%) ✅
Phase 3 index ↓ 4012ms 4134ms -122ms (-3%) ✅

Interactive Write Latency (during Phase 3)

Metric This PR Baseline Delta
Write p95 (baseline) ↓ 8ms 10ms -2ms (-20%) ✅
Write p95 (during phase 3) ↓ 12ms 9ms +3ms (+33%) ⚠️
Jank factor ↓ 1.5x 0.9x +0.6x (+67%) ⚠️
Concurrent writes ↑ 19 20 -1ms (-5%) ⚠️

SAF I/O Overhead (ContentProvider vs direct File read)

Measures Binder IPC cost added by ContentResolver per readFile() call.
Real SAF via ExternalStorageProvider will be higher on device; this is a lower bound.

Metric This PR Baseline Delta
Direct read / file ↓ 0.0ms 0.0ms 0 (0%)
Provider read / file ↓ 0.3ms 0.2ms +0ms (+65%) ⚠️
IPC overhead ratio ↓ 10x 6x +4x (+67%) ⚠️
↓ lower is better · ↑ higher is better

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant