終極虛幻引擎 (Unreal Engine) 版本控制大對決：Perforce P4 vs. Lore

在我為遊戲工作室和企業開發團隊提供日常諮詢的過程中，有一個問題經常主導著對話：Perforce P4 是否依然是 Unreal Engine 工作流程中無可爭議的王者？ 為了擺脫主觀意見和供應商的行銷話術，我設計了一個高度可重複、標準化的框架，客觀地將 P4 與版本控制領域的新興競爭對手進行基準測試 (Benchmark)。

這次全面的解析探討了為什麼必須根據真實、繁重的 Unreal Engine 專案參數來衡量版本控制的效能。我將逐步介紹用於將 P4 與 Epic Games 的新系統 Lore 進行對決的 AWS 架構和逼真資料集，提供確切的指令供您重現測試，並剖析這些指標對您工作室的基礎架構決策意味著什麼。

設計基準測試：方法論

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 所提供的專用後端架構。

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 的 stage 指令完全在用戶端運作，造成了巨大的瓶頸。
• 雖然 Lore 的 push 需要的 I/O 可以忽略不計，但其在暫存 (staging) 期間的用戶端記憶體佔用量卻非常驚人。

第二回合：獲取資料 (Sync vs. Clone)

數字背後的真相：

• 無論使用 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 開發中無可爭議的重量級王者。