성능
원칙: 측정하지 않은 성능 우위는 주장하지 않으며, 차이가 측정 잡음 안에 있으면 "개선"이나 "저하"라고 쓰지 않습니다.
측정 1 — 게임 테스트 서버 시작~종료 시간 (2026-10-19)
| 항목 | 값 |
|---|---|
| 명령 | :poly-bootstrap:startupBenchmark |
| 시나리오 | Mojang 게임 테스트 서버, 새 월드 생성 → minecraft:always_pass → 저장 → 종료 |
| 비교 | 바닐라(게임 jar를 클래스 경로에 두고 Poly 모드 로더 없이 실행) 대 Poly 모드 로더(개발용 모드 4개, 변환 규칙 4개, 데워진 변환 캐시) |
| 반복 | 각 5회, 1회 예열은 버림. 바닐라와 Poly 모드 로더를 번갈아 실행, 실행마다 새 디렉터리 |
| 환경 | Windows 11, JDK 25.0.3, Minecraft 26.2, Poly 모드 로더 0.1.0-alpha.1 |
| 변형 | 중앙값(초) | 표준편차(초) | 개별 실행(초) |
|---|---|---|---|
| 바닐라 | 7.137 | 0.122 | 6.99, 7.25, 6.96, 7.16, 7.14 |
| Poly Mod Loader | 7.225 | 0.312 | 7.84, 7.03, 7.23, 7.17, 7.33 |
결론: 중앙값 차이는 +0.09초(+1.2%)로, Poly 모드 로더 측 표준편차(0.31초) 안에 있습니다. 이 시나리오에서는 Poly 모드 로더 부트스트랩·검색·변환 계획의 비용을 측정 잡음과 구분할 수 없습니다. 성능 개선은 주장하지 않습니다.
원시 데이터는 Poly 모드 로더 저장소의 docs/benchmarks/2026-10-19-startup.json에 있습니다.
측정 2 — 같은 부하에서 서버 틱 시간·힙·GC (2026-10-21)
| 항목 | 값 |
|---|---|
| 명령 | :poly-bootstrap:tickBenchmark (약 7분, 창 없음) |
| 시나리오 | 게임 테스트 서버에서 데이터 팩 테스트가 1,200틱을 기다리는 동안 돼지 40마리 유지, 매 틱 16×16×16 블록 채우기·비우기. 데이터 팩이라 바닐라에서도 같은 일을 함 |
| 비교 | 바닐라 대 Poly 모드 로더(개발용 모드 5개, 변환 규칙 32개, 접근 확대 1개) |
| 측정 도구 | 틱마다 시간을 재는 에이전트 tools/tick-probe와 Java Flight Recorder를 양쪽에 똑같이 붙임. 실행마다 처음 200틱은 버림 |
| 반복 | 각 5회, 예열 1회는 버림, 번갈아 실행 |
| 환경 | Intel Core i9-14900HX, RAM 32 GB, Windows 11, JDK 25.0.3(G1, 기본 힙), Minecraft 26.2 |
실행 5회의 중앙값(괄호 안은 실행 간 표준편차):
| 지표 | 바닐라 | Poly 모드 로더 |
|---|---|---|
| 틱 p50 (ms) | 18.13 (±0.97) | 18.20 (±2.25) |
| 틱 p95 (ms) | 22.10 (±1.48) | 21.55 (±1.73) |
| 틱 p99 (ms) | 53.1 (±16.0) | 46.6 (±26.5) |
| 50ms를 넘은 틱 (%) | 1.10 | 0.99 |
| 피크 힙 사용량 (MiB) | 1,386 (±1,141) | 1,621 (±420) |
| GC 정지 합계 (ms) | 1,263 | 1,227 |
결론: 모든 지표의 차이가 실행 간 표준편차보다 작아 "유의한 차이 없음"입니다. 개선도 저하도 주장하지 않습니다. 피크 힙은 G1의 힙 크기 결정에 따라 실행마다 642~3,597 MiB로 흔들려, 이 측정으로는 메모리 차이를 판단할 수 없습니다.
원시 데이터는 Poly 모드 로더 저장소의 docs/benchmarks/2026-10-21-ticks.json에 있습니다.
측정 3 — 힙을 고정한 서버 틱 시간·힙·GC (2026-10-21)
| 항목 | 값 |
|---|---|
| 명령 | :poly-bootstrap:tickBenchmark -PtickBenchmarkHeap=2g |
| 시나리오 | 측정 2와 같지만 정육면체를 유리로 채움. 돌로 채우면 조명 계산 대기열이 실행 내내 커져서 힙 수치가 로더가 아니라 조명 엔진의 사용량을 반영했음 |
| 힙 | 양쪽 모두 -Xms2g -Xmx2g. GC 직후에 남은 힙의 최댓값도 기록 |
| 그 밖 | 측정 2와 같음 |
실행 5회의 중앙값(괄호 안은 실행 간 표준편차):
| 지표 | 바닐라 | Poly 모드 로더 |
|---|---|---|
| 틱 p50 (ms) | 12.97 (±2.23) | 12.25 (±1.44) |
| 틱 p95 (ms) | 15.60 (±2.94) | 14.48 (±1.01) |
| 틱 p99 (ms) | 18.12 (±3.25) | 15.85 (±0.94) |
| GC 직후 힙 최댓값 (MiB) | 158.1 (±12.7) | 157.4 (±10.7) |
| GC 횟수 | 18 | 18 |
| GC 정지 합계 (ms) | 365.3 (±62.5) | 368.3 (±56.6) |
결론: 힙을 고정하자 메모리를 비교할 수 있게 됐고, GC 직후 힙·GC 횟수·정지 시간 모두 바닐라와 구분할 수 없습니다. 틱 시간은 Poly 모드 로더 중앙값이 조금 낮지만 바닐라 쪽 표준편차 안이라 개선으로 주장하지 않습니다.
원시 데이터는 Poly 모드 로더 저장소의 docs/benchmarks/2026-10-21-ticks-fixed-heap.json에 있습니다.
측정 4 — 클라이언트 프레임 시간 (2026-10-21)
frameBenchmark: 저장된 월드를 클라이언트로 열고 30초 동안 모든 프레임(Minecraft.runTick)을 잽니다. vsync 끔, 프레임 제한 없음, 각 5회. Poly 모드 로더 쪽에는 매 프레임 그리기 작업을 하는 개발용 모드(HUD, 월드 위 그리기, 셰이더)가 들어 있습니다.
| 지표 | 바닐라 | Poly 모드 로더 + 개발용 모드 |
|---|---|---|
| 평균 FPS | 1,331 (±163) | 1,163 (±170) |
| 프레임 p50 (ms) | 0.656 (±0.052) | 0.800 (±0.075) |
| 프레임 p95 (ms) | 1.545 (±0.457) | 1.083 (±0.693) |
| 프레임 p99 (ms) | 2.070 (±0.579) | 1.962 (±0.747) |
결론: p50이 0.14ms 늘었으므로 측정된 저하로 기록합니다(60 FPS 프레임 예산의 0.9%). 로더 비용과 모드의 그리기 비용은 이 측정으로 나눌 수 없습니다. p95·p99와 평균 FPS의 차이는 실행 간 편차 안입니다.
원시 데이터는 Poly 모드 로더 저장소의 docs/benchmarks/2026-10-21-frames.json에 있습니다.
측정 5 — 실제 Fabric 모드 묶음의 시작 시간과 서버 틱 (2026-10-22)
| 항목 | 값 |
|---|---|
| 명령 | :poly-bootstrap:startupBenchmarkFabric, :poly-bootstrap:tickBenchmarkFabric -PtickBenchmarkHeap=4g |
| 시나리오 | 시작 시간은 측정 1, 틱은 측정 3과 같습니다(유리 정육면체, 양쪽 모두 힙 4 GiB 고정) |
| 비교 | 바닐라(모드 없음) 대 Poly 모드 로더 + 26.2 호환성 묶음의 Fabric 모드. jar 41개이고, 이 서버에서 안에 든 jar를 포함해 Fabric 모드 97개와 Mixin 설정 71개가 로드됩니다 |
| 비교하지 않은 것 | 같은 모드를 Fabric Loader로 실행한 경우. 그래서 이 측정은 Poly 모드 로더가 Fabric Loader보다 빠른지 느린지 말하지 않습니다. 모드 묶음을 Poly 모드 로더로 돌렸을 때 바닐라와 얼마나 다른지만 보여 줍니다 |
| 지표 | 바닐라 | Poly 모드 로더 + Fabric 모드 |
|---|---|---|
| 시작 시간 중앙값 (초) | 6.03 (±0.23) | 15.01 (±0.64) |
| 틱 p50 (ms) | 7.91 (±0.32) | 4.04 (±0.09) |
| 틱 p95 (ms) | 13.29 (±0.56) | 6.83 (±0.10) |
| 틱 p99 (ms) | 15.16 (±0.61) | 8.81 (±0.62) |
| GC 직후 힙 최댓값 (MiB) | 141.6 (±6.5) | 182.9 (±1.3) |
| GC 횟수 | 12 | 16 |
| GC 정지 합계 (ms) | 168.8 (±7.9) | 250.9 (±16.3) |
결론:
- 모드 묶음과 함께 시작이 9.0초 늘었고, GC 직후 힙이 41 MiB 많습니다. 둘 다 실행 간 편차보다 훨씬 커서 측정된 비용으로 기록합니다. 모드 97개의 초기화, 링크 검사, Mixin 설정 71개 적용이 모두 들어 있고, 이 측정으로 로더 몫과 모드 몫을 나눌 수 없습니다.
- 틱 시간은 바닐라의 약 절반입니다. Poly 모드 로더의 개선이 아닙니다. 묶음에 서버 최적화 모드 Lithium과 FerriteCore가 들어 있고, 이 서버에서 두 모드의 Mixin 설정이 로드됐으며 Mixin 적용 실패는 기록되지 않았습니다. Lithium을 뺀 변형은 돌리지 않았으므로 차이를 특정 모드 덕분이라고 하지 않습니다. 말할 수 있는 것은 "Lithium 같은 최적화 모드가 Poly 모드 로더에서도 적용되고, 이 부하에서 틱이 바닐라보다 짧았다"까지입니다.
원시 데이터는 Poly 모드 로더 저장소의 docs/benchmarks/2026-10-22-startup-fabric.json, docs/benchmarks/2026-10-22-ticks-fabric.json에 있습니다.
측정 6 — 실제 Forge 모드 묶음의 시작 시간과 서버 틱 (2026-10-23)
| 항목 | 값 |
|---|---|
| 명령 | :poly-bootstrap:startupBenchmarkForge, :poly-bootstrap:tickBenchmarkForge -PtickBenchmarkHeap=4g |
| 시나리오 | 측정 5와 같습니다. 시작 시간은 측정 1, 틱은 측정 3과 같습니다(유리 정육면체, 양쪽 모두 힙 4 GiB 고정) |
| 비교 | 바닐라(모드 없음) 대 Poly 모드 로더 + Forge 65.1.5 + 26.2 호환성 묶음의 Forge 모드. corpusForge가 게임 테스트 서버에 넣는 jar 그대로이며, 38개 중 32개가 실행됩니다(나머지 6개는 서버의 클라이언트 전용, POLY-COMPAT-209). 모든 실행에서 "Forge mod loading, version 65.1.5"를 확인했습니다 |
| 비교하지 않은 것 | 같은 모드를 Forge 자체 실행기로 실행한 경우. 그래서 이 측정은 Poly 모드 로더가 Forge보다 빠른지 느린지 말하지 않습니다. Forge와 모드 묶음을 Poly 모드 로더로 돌렸을 때 바닐라와 얼마나 다른지만 보여 줍니다 |
| 반복·틱 측정·환경 | 측정 3과 같습니다(Poly 모드 로더 0.1.0-alpha.18, 커밋 e1756cd 이후 + libIPN 고정) |
시작 시간(실행 5회, 초):
| 변형 | 중앙값 | 표준편차 | 개별 실행 |
|---|---|---|---|
| 바닐라 | 6.281 | 0.090 | 6.18, 6.38, 6.40, 6.28, 6.24 |
| Poly 모드 로더 + Forge 모드 | 22.864 | 0.865 | 21.36, 23.25, 22.86, 23.33, 21.93 |
서버 틱(실행 5회의 중앙값, 괄호 안은 실행 간 표준편차):
| 지표 | 바닐라 | Poly 모드 로더 + Forge 모드 |
|---|---|---|
| 실행당 측정 틱 수 | 1,006 | 1,007 |
| 틱 p50 (ms) | 8.13 (±0.21) | 12.49 (±0.31) |
| 틱 p95 (ms) | 9.81 (±0.40) | 15.08 (±4.21) |
| 틱 p99 (ms) | 12.79 (±0.93) | 20.93 (±9.10) |
| 가장 긴 틱 (ms) | 47.4 | 60.9 |
| 50ms를 넘은 틱 (%) | 0.00 | 0.70 |
| GC 직후 힙 최댓값 (MiB) | 139.2 (±2.2) | 267.3 (±2.4) |
| GC 횟수 | 12 | 21 |
| GC 정지 합계 (ms) | 185.0 (±17.9) | 564.8 (±138.5) |
| 가장 긴 GC 정지 (ms) | 39.0 | 61.2 |
결론:
- 시작 시간이 16.6초(+264%) 늘었습니다. 모든 Poly 모드 로더 실행이 모든 바닐라 실행보다 15초 이상 길어서 측정된 비용으로 기록합니다. 여기에는 Forge 파일 확인, 패치된 게임 jar, FML의 모드 탐색·레이어, Mixin, 모드 32개의 생성과 설정 파일 쓰기가 모두 들어 있습니다. 이 측정으로는 Poly 모드 로더 몫, Forge 몫, 모드 몫을 나눌 수 없습니다. 같은 세션의
startupBenchmark(개발용 모드만)는 바닐라 6.24초, Poly 모드 로더 6.98초였습니다. - 메모리: GC 직후 힙이 128 MiB(+92%) 많고, GC는 9번, 정지 합계는 380ms 더 많습니다. 차이가 양쪽 표준편차보다 훨씬 커서 Forge와 모드 묶음의 메모리 비용으로 기록합니다.
- 틱 시간: p50이 4.4ms(+54%) 깁니다. 다섯 실행 모두 Poly 모드 로더 쪽이 12.25
13.06ms, 바닐라가 7.838.36ms로 겹치지 않아 측정된 비용으로 기록합니다. 다만 이 PC는 같은 세션에서 실행마다 p50이 약 8ms와 약 12.3ms 두 무리로 갈렸습니다. 같은 세션의tickBenchmark(개발용 모드만, 같은 4 GiB 힙)는 바닐라 8.38·8.92·8.82·8.59·12.30ms, Poly 모드 로더 7.70·12.47·7.43·12.53·12.29ms였습니다. 그래서 Forge 쪽 실행이 모두 느린 무리에 든 것이 기계 상태 때문인지는 이 측정으로 가릴 수 없습니다. Forge 이벤트 버스와 모드의 틱 처리 비용은 따로 재지 않았습니다. - p95·p99는 Poly 모드 로더 쪽 표준편차가 커서(한 실행의 가장 긴 틱 118ms, 같은 실행의 가장 긴 GC 정지 99.9ms) 중앙값만 비교합니다.
원시 데이터는 Poly 모드 로더 저장소의 docs/benchmarks/2026-10-23-startup-forge.json, docs/benchmarks/2026-10-23-ticks-forge.json에 있습니다.
측정하지 않은 것
- 모드 없이 Poly 모드 로더만 띄운 클라이언트 프레임 시간(로더 비용과 모드 비용 분리)
- 할당률, 청크 생성 시간
- 같은 Fabric 모드 묶음을 Fabric Loader로 실행한 비교(측정 5), Lithium을 뺀 변형
- Fabric 모드 묶음을 넣은 클라이언트 프레임 시간, Forge 모드 묶음
- 같은 Forge 모드 묶음을 Forge 자체 실행기로 실행한 비교(측정 6), Forge 이벤트 버스·모드별 틱 비용
- JMH 마이크로벤치마크(이벤트 디스패치, 변환 계획)
- 다른 하드웨어
이 항목들을 측정하기 전까지 성능 목표(프레임 p95 5% 개선 등)는 목표일 뿐 결과가 아닙니다.