Task #1537: bench — 단계별 처리 성능 계측 CLI 서브커맨드#1538
Conversation
postmelee
left a comment
There was a problem hiding this comment.
@planet6897님, bench CLI 추가 작업 확인했습니다.
기능 방향과 문서화는 적절하고, 로컬 검증도 주요 게이트는 통과했습니다. 다만 현재 구현은 성능 계측 자동화에서 실패를 성공처럼 숨길 수 있는 부분이 있어, 아래 두 항목은 merge 전에 수정이 필요합니다.
수정 요청:
- render 단계에서 페이지 렌더링 실패를 파일 처리 실패로 전파해 주세요.
- 하나 이상의 입력 파일 처리 실패가 있으면 프로세스 종료 코드를 non-zero로 만들어 주세요.
로컬 확인:
- cargo fmt --check: passed
- cargo build --release --bin rhwp: passed
- cargo clippy --all-targets -- -D warnings: passed
- cargo test --release --lib: 1937 passed / 0 failed / 6 ignored
- rhwp bench samples/hwpx_sample2.hwpx samples/task-001.hwp -n 1 --tsv output/poc/pr1538/bench.tsv: passed
| // render: 전 페이지 SVG 렌더 | ||
| let t = Instant::now(); | ||
| for p in 0..pages { | ||
| let _ = core.render_page_svg_native(p); |
There was a problem hiding this comment.
수정 요청입니다. 현재 render_page_svg_native(p)의 Result를 버리고 있어서, 특정 페이지 렌더링이 실패해도 bench가 성공한 것처럼 render 시간을 보고할 수 있습니다.
bench는 parse/layout/render/serialize 단계별 계측 명령이므로 render 단계 실패도 파일 처리 실패로 전파해야 합니다. 예를 들면 core.render_page_svg_native(p).map_err(|e| format!("{e:?}"))?;처럼 처리해 주세요.
|
|
||
| let mut rows: Vec<Row> = Vec::new(); | ||
| for f in &files { | ||
| match bench_one(f, iters) { |
There was a problem hiding this comment.
수정 요청입니다. 현재 bench_one 실패를 출력만 하고 계속 진행하기 때문에, 입력 파일이 없거나 parse/render/serialize 실패가 발생해도 프로세스 종료 코드가 0으로 남습니다. 실제로 /no/such/file 입력에서도 실패 메시지는 출력되지만 exit code는 0입니다.
성능 계측은 CI나 스크립트에서 자동화될 가능성이 높으므로, 하나 이상의 파일 처리 실패가 있으면 non-zero로 종료해 주세요. 실패 개수를 추적한 뒤 마지막에 std::process::exit(1)을 호출하거나, run이 결과/exit code를 반환하도록 정리하는 방식이면 충분합니다.
PR edwardkim#1538 리뷰(@postmelee, CHANGES_REQUESTED) 수정 요청 2건 반영: - render 단계: render_page_svg_native 의 Result 를 버리지 않고 ?로 전파해 페이지 렌더 실패를 파일 처리 실패로 올린다(성공처럼 숨겨지지 않게). - run(): 실패 개수를 집계해 하나 이상 실패 시 std::process::exit(1). CI·스크립트 자동화에서 실패가 exit 0 으로 가려지지 않게 한다.
|
@postmelee 수정 요청 2건 반영했습니다 (커밋
검증(exit code):
로컬: 추가로 base를 최신 |
대용량 HWP/HWPX 처리 성능을 재현 가능한 수치로 계량. parse/layout/render/serialize 를 워밍업 1회 후 N회(기본 3) median(ms) 으로 보고한다. - src/diagnostics/bench.rs: parse(parse_document) · layout(=load−parse) · render(전 페이지 render_page_svg_native) · serialize(serialize_hwpx) 계측. 파일별 크기/쪽수 + 단계별 median + total 표, --batch 전수, --tsv 산출(부모 폴더 자동 생성). - main.rs: bench 디스패치 + help. cli_commands.md 동기화. - mydocs/report: 측정 보고서(i7-8850H/release/N=5). 단일 머신·상대 지표 명시(절대수치 단정 회피). 검증: release 빌드/clippy 무경고. 대표 9파일 측정 — 10MB HWP(20쪽) 열기≈0.34s, 렌더≈0.78s, 저장≈0.74s, total≈1.9s. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PR edwardkim#1538 리뷰(@postmelee, CHANGES_REQUESTED) 수정 요청 2건 반영: - render 단계: render_page_svg_native 의 Result 를 버리지 않고 ?로 전파해 페이지 렌더 실패를 파일 처리 실패로 올린다(성공처럼 숨겨지지 않게). - run(): 실패 개수를 집계해 하나 이상 실패 시 std::process::exit(1). CI·스크립트 자동화에서 실패가 exit 0 으로 가려지지 않게 한다.
postmelee
left a comment
There was a problem hiding this comment.
@planet6897님, 수정 반영 감사합니다.
기존 Request changes 항목 2건은 최신 커밋에서 반영된 것을 확인했습니다.
- render 단계 실패가 파일 처리 실패로 전파됨
- 하나 이상의 파일 처리 실패 시 non-zero exit 처리됨
추가 검토 중 --tsv 쓰기 실패도 자동화 관점에서는 non-zero exit이어야 한다고 판단해, 작은 follow-up 보정 커밋을 제가 PR head에 추가했습니다.
로컬에서는 fmt / diff check / clippy / release build와 bench 성공·실패 스모크를 확인했습니다. 이제 최신 head 기준 CI가 완료되면 review decision을 갱신하겠습니다.
postmelee
left a comment
There was a problem hiding this comment.
@planet6897님, PR #1538 최신 head 10ed345 기준으로 재검토했습니다.
기존 Request changes 항목은 반영된 것을 확인했습니다.
- render 단계 실패가 파일 처리 실패로 전파됨
- 하나 이상의 파일 처리 실패 시 non-zero exit 처리됨
추가 검토 중 --tsv 쓰기 실패도 자동화 관점에서는 non-zero exit이어야 한다고 판단해, collaborator follow-up으로 아래 보정 커밋을 추가했습니다.
- a6469c8
bench: fail on TSV write errors
리뷰 기록 문서도 PR head에 포함했습니다.
- 3fd038f
docs(pr): record PR #1538 review
로컬 검증:
- cargo fmt --check
- git diff --check
- cargo clippy --all-targets -- -D warnings
- cargo build --release --bin rhwp
- 정상 bench 입력: exit 0
- 없는 파일 입력: exit 1
- TSV 쓰기 실패 입력: exit 1
이전 기본 구현 검증에서는 cargo test --release --lib도 1937 passed / 0 failed / 6 ignored로 통과했습니다.
최신 head 기준 GitHub Actions도 Build & Test, CodeQL, Render Diff가 통과했고, WASM Build는 기존과 같이 skipped입니다.
변경은 bench 진단 CLI 추가와 실패 전파 보정에 한정되어 있고, renderer 출력 로직 자체를 바꾸지 않습니다. 문서에는 측정값이 머신/빌드 의존이며 같은 환경의 상대 비교·회귀 추적 지표라는 한계도 명시되어 있습니다.
Blocking finding 없습니다. Approve합니다.
|
@planet6897님 감사합니다. PR #1538 머지 완료했습니다. 이번 PR로 머지 정보: 검토 중 자동화 신뢰성 관련 보정을 함께 반영했습니다.
Contributor credit:
검증:
이 PR은 진단 CLI 추가이며 renderer 출력 로직 자체는 변경하지 않습니다. Canvas visual diff도 통과했습니다. #1537 은 자동 close되지 않아 별도 확인 후 수동 close하겠습니다. |
개요
대용량 HWP/HWPX 처리 성능을 재현 가능한 수치로 계량하는
bench서브커맨드 신설.(closes #1537)
명령
워밍업 1회 후 N회(기본 3) median(ms) 단계별 계측:
parse— 바이트→IR (parse_document)layout— parse+layout 로드 − parse (근사)render— 전 페이지 SVG (render_page_svg_native)serialize— Document→HWPX (serialize_hwpx, 저장 비용)파일별 크기/쪽수 + 단계별 median + total 표, 다파일 합계·쪽당 평균,
--tsv산출.변경
src/diagnostics/bench.rs신설 +main.rs디스패치/help +cli_commands.md동기화.mydocs/report/task_m100_1537_report.md측정 보고서.검증
저장≈0.74s, total≈1.9s. (절대 수치는 머신·빌드 의존 — 동일 환경 상대·재현 지표)
한계 (보고서 명시)
load−parse근사(음수→0 클램프). 메모리 미측정. 단일 머신. → 후속.🤖 Generated with Claude Code