終極虛幻引擎 (Unreal Engine) 版本控制大對決：Perforce P4 vs. Lore
在我為遊戲工作室和企業開發團隊提供日常諮詢的過程中，有一個問題經常主導著對話：Perforce P4 是否依然是 Unreal Engine 工作流程中無可爭議的王者？ 為了擺脫主觀意見和供應商的行銷話術，我設計了一個高度可重複、標準化的框架，客觀地將 P4 與版本控制領域的新興競爭對手進行基準測試 (Benchmark)。
這次全面的解析探討了為什麼必須根據真實、繁重的 Unreal Engine 專案參數來衡量版本控制的效能。我將逐步介紹用於將 P4 與 Epic Games 的新系統 Lore 進行對決的 AWS 架構和逼真資料集，提供確切的指令供您重現測試，並剖析這些指標對您工作室的基礎架構決策意味著什麼。
TL;DR：核心重點
本次基準測試將業界老將 Perforce P4 直接與 Epic Games 最近在芝加哥 Unreal Fest 上首度公開的版本控制解決方案 Lore 進行對決。使用中等規模的 UE 資料集並追蹤標準開發人員操作（新增、提交、同步和複製），結果是非常決定性的：
- 速度 (Velocity)： 透過我們的伺服器部署套件 (SDP) 部署的 P4 伺服器，在執行標準規模的程式碼提交時，速度比 Lore 快 2.7 倍.
- 資源佔用 (Resource Footprint)： 雖然初始儲存庫提取（P4 的 ‘sync’ 與 Lore 的 ‘clone’）完成時間大致相同，但 Lore 被證明極其消耗資源，其記憶體消耗量是 P4 的 14 倍.
設計基準測試：方法論
Unreal Engine 不再只適用於獨立遊戲；它驅動著企業級視覺化、虛擬製作和 3A 大作。這些龐大的專案帶來了獨特的版本控制摩擦：傳輸巨大的二進位檔案、管理複雜的團隊依賴關係以及避免工作流程瓶頸。標準軟體儲存庫相比之下相形見絀。
為了確保測試反映現實，資料集必須包含：
- 大量的純文字原始碼檔案。
- 繁重的二進位資產（
.uasset 和 .umap 檔案），以及音訊和圖形等可壓縮媒體的混合體。
我使用我們的伺服器部署套件 (SDP) 部署了 Perforce。SDP 是 Linux/Windows 腳本的集合，可立即配置高度最佳化、企業級的 P4 伺服器，在不改變核心 P4 執行檔的情況下標準化管理任務。
AWS 雲端實驗室
由於現代工作室嚴重依賴雲端基礎架構來支援遠端、全球分佈的團隊，因此在 AWS 中執行此基準測試提供了最真實且可重現的基準線。
測試的軟體版本：
- Perforce P4:
2026.1 (Patch 2) - Lore:
0.8.5
基礎架構與網路配置
測試位在同一個資料中心機架上的用戶端和伺服器，並不能反映開發人員的實際工作情況。為了模擬從家庭辦公室連線的遠端開發人員，我在用戶端機器上人為地注入了 30ms 的網路延遲.
硬體規格 (執行 Ubuntu 24.04)：
- 伺服器 (Benchserver)：
m7a.2xlarge（8 vCPU，32GB RAM）— 中型 UE 團隊的理想選擇，配備 gp3 儲存磁碟區。 - 用戶端 (Benchclient)：
c7a.xlarge，配備 200GB /data 磁碟區（10k IOPS，500MB/s 吞吐量）。
關於 Git 的簡短說明： 雖然 Git 對於標準的純文字程式碼庫來說非常出色，但要管理遊戲引擎龐大的二進位有效負載，則需要像 P4 和 Lore 所提供的專用後端架構。
| 檔案系統 (Filesystem) | 大小 | 掛載點 (Mount Point) | IOPS | 吞吐量 (MB/s) |
|---|
| /dev/nvme2n1p1 | 40G | /hxlogs | 10k | 500 |
| /dev/nvme3n1p1 | 50G | /hxmetadata | 10k | 500 |
| /dev/nvme1n1p1 | 750G | /hxdepots | 10k | 700 |
P4 架構遵循 SDP 最佳實務：一個 OS 根磁碟區加上三個獨立的資料磁碟區，分別用於日誌 (journals/logs)、資料庫和版本檔案。Lore 伺服器同樣託管在 /hxdepots 磁碟區上以確保公平競爭。(注意：測試期間任何時候都只有一個服務處於活動狀態)。
策劃貼近現實的資料集
僅僅從 GitHub 提取原始 UE 原始碼（約 223,000 個檔案，大小僅 2.68GB）並不能複製遊戲開發中資產繁重的現實。
為了解決這個問題，我提取了 Unreal Engine 5.8.1 版本的 commit (71fe36aac5a8df5ccd66c763ffc902b29b6a9c43)，安裝了依賴項，並執行了 Setup.sh。然後我獨立出「Engine」目錄，產生了一個高度準確、重量級的資料集，包含 362,028 個檔案，總計 91GB.
perforce@benchclient:/data/UnrealEngine$ git ls-files --cached --others --exclude-standard -z | \
xargs -0 stat -c '%s' | \
awk '{s+=$1} END { \
printf "Files: %d\nSize: %.2f GiB\n", NR, s/1024/1024/1024 \
}'
Files: 223987
Size: 2.68 GiB
perforce@benchclient:/data/UnrealEngine$ du -sh Engine/
91G Engine/
perforce@benchclient:/data/UnrealEngine$ find Engine/ -type f | grep -v .git | wc -l
362028
所有的遙測資料都是使用 P4Prometheus、node_exporter 和 Grafana 精心捕獲的，以 15 秒的間隔抓取資料。
結果：正面交鋒效能
第一回合：新增與提交檔案
為了確保對等，我將 P4 的多執行緒提交功能與 Lore 的原生工作流程進行了比較：
- P4 工作流程：
p4 add + p4 submit（使用 10 個執行緒） - Lore 工作流程：
lore stage + lore commit + lore push
P4 最佳化提示： 預設情況下，P4 會掃描檔案以確定它們是文字（會進行壓縮）還是二進位（保持原樣）。對於 362k 個檔案，這種掃描會帶來不必要的延遲。在 P4 2026.1 中設定 filesys.binaryscan=0 即可完全消除此額外開銷。
| 指標 | P4 總計 | Lore 總計 | 裁決 |
|---|
| 實際耗時 (Wall Clock) | 5:15 | 14:30 | P4 勝出 (Lore 花費 2.76 倍時間) |
| 用戶端 User CPU | 178.16s | 1,278.59s | P4 勝出 (Lore 消耗多 7.18 倍 CPU) |
| 用戶端 Sys CPU | 81.42s | 152.85s | P4 勝出 (Lore 使用多 1.88 倍 Sys CPU) |
| 最大用戶端記憶體 (RSS) | 108 MB | 13,392 MB | P4 佔絕對優勢 (Lore 使用多 124 倍 RAM) |
數字背後的真相：
- P4 在提交階段在伺服器端高效地處理繁重的工作，並透過平行執行緒實現了極佳的擴展。
- Lore 的
stage 指令完全在用戶端運作，造成了巨大的瓶頸。 - 雖然 Lore 的
push 需要的 I/O 可以忽略不計，但其在暫存 (staging) 期間的用戶端記憶體佔用量卻非常驚人。
第二回合：獲取資料 (Sync vs. Clone)
| 指標 | P4 Sync (4 個執行緒) | Lore Clone | 裁決 |
|---|
| 實際耗時 (Wall Clock) | 3:10.09 | 3:22.12 | P4 勝出 (微弱優勢，Lore 花費 1.06 倍時間) |
| User CPU | 278.47s | 211.10s | Lore 勝出 (P4 使用多 1.32 倍 CPU) |
| Sys CPU | 55.37s | 170.01s | P4 勝出 (Lore 使用多 3.07 倍 Sys CPU) |
| CPU % | 175% | 188% | 統計學平手 |
| 最大記憶體 (RSS) | 988 MB | 13,720 MB | P4 佔絕對優勢 (Lore 消耗多 13.9 倍 RAM) |
數字背後的真相：
- 無論使用 4 個還是 10 個執行緒，P4 的同步時間都保持不變，這表明存在硬體的 I/O 瓶頸，而非軟體限制。
- Lore 是高度網路密集型的，儘管從磁碟讀取的資料量幾乎相同，但它在網路上推送了 51.95 GB 的資料，而 P4 為 37.68 GB（傳出流量增加了約 38%）。
- Lore 導致了明顯更高的伺服器爭用 (contention)，忙碌時間高達 40.4%，而 P4 為 18.3%。
重現基準測試
Perforce P4 執行
# 1. 建立 UE5 depot 並初始化 stream
$p4 --field Type=stream depot -o UE5 \vert{} p4 depot -i$ p4 stream -t mainline -o //UE5/main | p4 stream -i
# 2. 產生目標檔案清單
$cd /data/UnrealEngine$ find Engine/ -type f | grep -v .git > ../filelist.txt
# 3. 配置工作區、新增檔案並提交
$p4 --field Stream=//UE5/main client -o Bench_ws \vert{} p4 client -i$ nohup /usr/bin/time -v p4 -Ztrack -x ../filelist.txt add > ../add.out &
$ nohup /usr/bin/time -v p4 -Ztrack submit -d "New files" > ../submit.out &
# 4. 同步至乾淨的工作區
$ mkdir /data/ws2 && cd /data/ws2
$p4 --field Stream=//UE5/main client -o Bench_ws2 \vert{} p4 client -i$ nohup /usr/bin/time -v p4 -Ztrack sync --parallel=threads=4 > ../sync.out &
Lore 執行
# 1. 初始化 Lore 儲存庫
$lore repository create lore://benchserver:41337/UE5$ cd /data/UnrealEngine
# 2. Stage、Commit 和 Push 工作流程
$ nohup /usr/bin/time -v lore stage --targets ../file_list.txt > ../stage.txt &
$ nohup /usr/bin/time -v lore commit "Test of UE5 Engine" > ../commit.txt &
$ nohup /usr/bin/time -v lore push > ../push.txt &
# 3. 複製 (Clone) 至乾淨的目錄
$mkdir /data/lore_ws && cd /data/lore_ws$ nohup /usr/bin/time -v lore clone lore://benchserver:41337/UE5 > ../clone.txt &
調校 P4 伺服器
雖然 SDP 提供了極佳的預設值，但要匹配這個特定的基準測試，需要調整平行執行緒並停用二進位掃描：
filesys.binaryscan: 0
net.parallel.max: 20
net.parallel.threads: 4
net.parallel.submit.threads: 4
net.parallel.sync.svrthreads: 150
最終裁決：哪款引擎能驅動您的工作室？
只要設定得當，Perforce P4 和 Lore 都展現出強大的後端解決方案能力。然而，它們的架構理念決定了截然不同的基礎架構成本和使用者體驗。
Lore 預設採用激進的平行處理，這使得它一開始就極其消耗 RAM。對於不斷擷取和提交海量 UE 資料集的團隊來說，P4 的速度明顯快得多.
雖然複製/同步的速度大致平分秋色，但在雲端環境中大規模部署時，P4 呈現出巨大的成本優勢。透過減少約 38% 的傳出 (egress) 資料傳輸，並以 Lore 用戶端記憶體佔用量的一小部分運作，工作室可以為其開發人員配備更精簡、更便宜的執行個體 (instances)。Lore 最終可能會透過資產繁重專案的伺服器端重複資料刪除 (deduplication) 來抵消部分儲存成本，但這必須與其龐大的網路傳輸量和高 RAM 需求進行仔細權衡。
您的版本控制系統守護著工作室最寶貴的智慧財產權。P4 之所以能保持其行業標準的地位，是因為它能輕鬆擴展至 PB 級 (Petabytes) 的資料量，無縫處理二進位資產的獨佔鎖定 (exclusive locking)，並與美術人員和開發人員的工作流程完美整合。結合廣泛的 GUI 生態系統和全球企業支援，Perforce 依然是 Unreal Engine 開發中無可爭議的重量級王者。
