Evaluating Unreal Engine Version Control: A Performance Benchmark of Perforce P4 vs. Lore

This breakdown explores why version control performance must be measured against authentic Unreal Engine project parameters, details the AWS infrastructure and dataset utilized to test P4 and Lore, and provides the exact configuration commands so you can independently verify the results. Finally, we will unpack what these metrics mean for studios deciding on their next version control backbone.

Core Takeaways: P4 vs. Lore

This initial test puts Perforce P4 head-to-head with Lore, the new version control solution recently unveiled by Epic Games at Unreal Fest Chicago. To capture a true reflection of how these systems handle real-world Unreal Engine workloads, I deployed a medium-scale UE dataset and tracked standard operations: adding, submitting, syncing, and cloning.

The benchmark revealed the following:

• Speed: A P4 server deployed via our Server Deployment Package (SDP) completes standard-sized submits 2.7 times faster than Lore.
• Resource Efficiency: During initial repository pulls (termed ‘syncs’ in P4 and ‘clones’ in Lore), the execution times are nearly identical, but Lore consumes approximately 14 times more memory than P4.

Methodology: Testing Unreal Engine Version Control

Unreal Engine powers everything from indie games to enterprise-grade visualizations, bringing unique version control hurdles. These projects demand the storage and rapid transfer of massive binary files, complex team dependencies, and heavy initial setup phases. Without effective version control, scaling teams will inevitably hit collaboration bottlenecks.

To accurately simulate this environment, the test dataset needed to reflect:

• A massive volume of text-based source code files.
• Heavy binary assets (.uasset / .umap) alongside compressible audio, video, and graphics files.

I deployed P4 utilizing our Server Deployment Package (SDP). The SDP provides a suite of Linux/Windows scripts that establish a highly optimized, enterprise-ready P4 server out of the box, standardizing tasks like upgrades and proxy creation. The underlying P4 executable remains identical to a standard package installation.

The AWS Cloud Test Environment

Because modern studios rely heavily on cloud infrastructure for geographic flexibility, benchmarking in AWS provides the most relevant and reproducible data.

For the server, I provisioned an Amazon EC2 m7a.2xlarge instance (8 vCPUs, 32GB RAM)—a standard spec for mid-sized Unreal Engine teams.

Tested Software Versions:

• Perforce P4: 2026.1 (Patch 2)
• Lore: 0.8.5

Infrastructure & Configuration Specifics

To simulate real-world remote work conditions, placing the client and server in the same immediate data center isn’t realistic. Therefore, I artificially injected a 30ms network latency on the client machine to mimic a developer connecting from a home office.

Environment Details (Ubuntu 24.04):

• Benchserver: m7a.2xlarge equipped with gp3 storage volumes.
• Benchclient: c7a.xlarge equipped with a 200GB /data volume (10k IOPS, 500MB/s throughput).

Note on Git Context: While Git’s open-source architecture makes it incredibly versatile for standard codebases (powering platforms like GitHub and GitLab), handling the massive binary payloads of game engines requires specialized backend storage architectures, which is where P4 and Lore step in.

The P4 deployment utilized SDP best practices: an OS root volume alongside three dedicated data volumes (journal/logs, database, and versioned files/librarian). The Lore server was identically deployed on the /hxdepots volume. Note: Only one service (p4d or lore) was active during its respective benchmark.

The Unreal Engine source code was pulled directly from Epic’s GitHub repository using the 5.8.1 release commit (71fe36aac5a8df5ccd66c763ffc902b29b6a9c43). I installed the required dependencies and executed Setup.sh to generate the intermediate assets.

Curating the Test Dataset

Relying solely on the raw Git repository source files (roughly 223,000 files totaling just 2.68GB) fails to represent an authentic Unreal Engine project, which relies heavily on weighty graphics and audio data.

To fix this, I isolated the “Engine” directory post-Setup.sh execution. This resulted in a highly realistic dataset comprising 362,000 files and 91GB of data.

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

Telemetry metrics were captured using P4Prometheus, node_exporter, and Grafana on both client and server nodes with a 15-second scraping interval.

The Results: P4 vs. Lore

Adding & Submitting Operations

To create an apples-to-apples comparison, I matched P4’s parallel thread submission capability against Lore’s standard workflow. The workflows are:

• P4: p4 add + p4 submit (10 threads)
• Lore: lore stage + lore commit + lore push

Optimization Note for P4: By default, P4 compresses text files but leaves specific binaries uncompressed. Historically, P4 scanned files to determine the type, which adds overhead for 362k files. Setting filesys.binaryscan=0 in P4 2026.1 eliminates this latency.

Observational Notes:

• P4’s server-side operations happen primarily during the submit phase (69.1% CPU utilization, 32.51 GB disk writes) and scale exceptionally well with parallel processing.
• Lore’s stage phase happens entirely client-side, creating a significant performance bottleneck.
• Lore’s commit mimics P4’s submit regarding disk writes (35.43 GB) but operates at a lower server CPU utilization (13.8%). Lore’s push requires negligible I/O.

Fetching Files: P4 Sync vs. Lore Clone

Observational Notes:

• The P4 sync duration remained virtually identical whether using 4 or 10 threads, indicating an I/O bottleneck.
• Lore pushes significantly more data across the network: 51.95 GB transmitted compared to P4’s 37.68 GB (a 38% increase), despite disk read volumes being nearly identical.
• Lore generated higher server contention, registering 33.1% iowait and 40.4% busy time, versus P4’s 14.9% iowait and 18.3% busy time.

How to Reproduce the Benchmark

Perforce P4 Configuration

# 1. Establish the UE5 depot and stream
$ p4 --field Type=stream depot -o UE5 | p4 depot -i 
$ p4 stream -t mainline -o //UE5/main | p4 stream -i 

# 2. Prepare the file list
$ cd /data/UnrealEngine 
$ find Engine/ -type f | grep -v .git > ../filelist.txt 
 
# 3. Create workspace and execute the add/submit
$ p4 --field Stream=//UE5/main client -o Bench_ws | 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. Syncing to a fresh workspace
$ mkdir /data/ws2 && cd /data/ws2 
$ p4 --field Stream=//UE5/main client -o Bench_ws2 | p4 client -i 
$ nohup /usr/bin/time -v p4 -Ztrack sync --parallel=threads=4  > ../sync.out &

Lore Configuration

# 1. Initialize Lore repository
$ lore repository create lore://benchserver:41337/UE5 
$ cd /data/UnrealEngine 

# 2. Stage, Commit, and 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. Cloning to a fresh directory
$ mkdir /data/lore_ws && cd /data/lore_ws 
$ nohup /usr/bin/time -v lore clone lore://benchserver:41337/UE5 > ../clone.txt &

P4 Server Tuning Variables

The SDP generates a heavily optimized configuration by default. To match this exact benchmark, ensure net.parallel.threads=4 and disable binary scanning to speed up file additions:

filesys.binaryscan: 0
net.parallel.max: 20
net.parallel.threads: 4
net.parallel.submit.threads: 4
net.parallel.sync.svrthreads: 150

The Verdict: Choosing the Right Engine for Your Studio

Both Perforce P4 and Lore exhibit strong capabilities when properly tuned and deployed. However, Lore’s architecture is highly reliant on aggressive parallel processing and consumes significantly more RAM out of the gate.

For studios routinely pushing massive UE datasets, P4 proved drastically faster for add and submit workflows. While fetch speeds were comparable, P4 demonstrated a major cost-saving advantage in cloud environments by moving roughly 38% less egress data across the network and requiring a fraction of the client RAM. While Lore might recoup some storage expenses via server-side deduplication, studios must balance that against higher network egress fees and the need to provision heavier, more expensive client workstations to handle its RAM demands.

Version control is the bedrock of your studio’s intellectual property. P4 retains its status as the industry standard because it scales effortlessly across Petabytes of data, natively handles exclusive locking for unmergeable binary assets, and integrates seamlessly into developer and artist pipelines. Backed by a mature ecosystem of GUI tools and global support, P4 continues to deliver unmatched ROI for Unreal Engine teams.

Ready to benchmark P4 yourself? Small teams can run Perforce P4 completely free for up to 5 users and 20 workspaces.