KiCad 웹 포트 제작자는 WebAssembly의 비동기 처리를 Asyncify에서 JSPI로 바꾼 뒤 번들 크기와 로딩 시간이 줄고 보드 조작 FPS가 높아졌다고 밝혔다. 측정은 M4 Max 64GB MacBook Pro에서 진행했으며, 제작자는 주요 브라우저가 모두 JSPI를 지원한다고 설명한다.
| 항목 | Asyncify | JSPI |
|---|---|---|
| 편집기 원본 크기(-O1) | 118.6 MB | 63.3 MB |
| 편집기 Brotli 크기(-O1) | 21.0 MB | 10.6 MB |
| vme-wren 콜드 로드 | 2,145 ms | 1,063 ms |
| vme-wren 보드 열기 | 6,347 ms | 3,317 ms |
| vme-wren 보드 이동(FPS) | 11.9 | 18.1 |
| Jetson AGX Thor 콜드 로드 | 2,135 ms | 1,050 ms |
| Jetson AGX Thor 보드 열기 | 14,651 ms | 8,013 ms |
| Jetson AGX Thor 보드 이동(FPS) | 11.4 | 14.4 |
보드 측정은 vme-wren과 Jetson AGX Thor 보드에서 진행했다. 제작자는 JSPI로 바꾸면서 성능과 번들 크기뿐 아니라 빌드 시간, 빌드 메모리 사용량, 빌드 시스템 복잡성도 개선됐다고 설명한다.
Asyncify는 비동기 작업이 필요한 WebAssembly 코드가 중단됐다가 다시 실행되도록 코드를 변환하고 프로그램 상태를 저장·복원한다. 제작자에 따르면 이 방식은 번들 크기와 실행 시간에 부담을 주고, 간접 호출이 많은 KiCad와 wxWidgets에서는 빌드 시간과 메모리 사용량도 늘렸다. 여러 중단 지점과 KiCad 자체 코루틴을 함께 처리하면서 오류를 진단하기 어려워지는 문제도 있었다.
JSPI는 WebAssembly 엔진에 실행을 중단하고 재개하는 네이티브 API를 제공한다. 제작자는 전환 작업이 며칠 걸렸으며 코드와 스택 관련 문제가 줄고 WASM 워커 스레드의 간헐적 실패도 사라졌다고 밝혔다. 다만 JSPI를 쓰면 iOS 27 이전 버전은 지원할 수 없다고 덧붙였다. Asyncify 설명은 관련 글에서 확인할 수 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요