Unreal performance review
Insights traces and GPU captures on your target hardware, memory high-water marks, synchronous loads and shader compilation cost — put into enough production context for your team to act on Monday.
Full-access engagement
Five consulting days, usually spread across one to two calendar weeks. This is the minimum engagement for work inside your build, source and project content.
I work inside your approved environment, review material asynchronously and use calls only where conversation adds value.
Scope
Insights traces and GPU captures on target hardware: median and p99 frame time, the worst repeatable hitch, per-pass cost, draw-call and shader-permutation counts.
High-water mark against the platform ceiling, streaming pool behaviour, level transitions, synchronous loads, growth over a long session and which subsystem owns it.
Cook and shader compilation where they affect what ships. The full loop — DDC hit rates, sync-to-playable, CI turnaround, senior time — is the engineering effectiveness review.
Who owns each subsystem, what cert dates and milestones allow, and the order the fixes can realistically happen in given who is free.
Before full access
The earlier steps on the pricing page use a brief, a call and evidence your team chooses to provide. They are designed to establish whether a full-access review is the right next move.
A selected trace, GPU capture, build log or planning document can be enough to answer a specific question without granting access to a repository or working build.
No repository, build or project-content access. If the answer needs full access, that is stated plainly.
Interviews, delivery context and existing evidence establish the questions a full-access review must answer and the conditions it needs to start cleanly.
No repository, build or project-content access. The engagement clock starts when the agreed environment is ready.
Method
A build on target hardware, capture permission, the current plan, and the questions the review must answer. The kit stays yours; the pre-engagement checklist goes out before you book.
Capture sessions across the worst-performing content, then focused conversations with the engineers closest to it.
If the p99 is dominated by one synchronous load, you hear about it on day two, not in the report.
Severity, evidence, consequence, recommendation, owner and likely effort.
Deliverables
Each finding with the capture attached, the cost in milliseconds or MiB, the cause, and what happens if it is left.
What to do before cert, what to do after, what to leave alone — with rough engineer-days against each.
A 90-minute session with the engineers who will do the work and the people who decide what they work on.
The evidence
Findings arrive with the capture attached and the reasoning written out, so your engineers can disagree with the conclusion by looking at the same data rather than by taking my word for it.
What a hitch actually looks like. The GPU is idle for most of the bad frame. Nothing is slow — the game thread is blocked, and everything downstream is waiting for it. Reconstruction using the fictional figures from the sample report.
Where the GPU frame went. One unbudgeted translucency pass costs more than the entire base pass. That is a conversation with the VFX lead about overdraw and resolution, not an engine problem. Reconstruction using the fictional figures from the sample report.
What a finding looks like when it lands
Findings are ranked by what they return, and the report states the before figure, the target and the expected after. Here is the shape, using the figures from the sample report.
−45%Remove one synchronous load on first use. Gold marker is the 16.67 ms budget.
Illustrative, from the fictional sample report.
−66%Shared DDC reachable from every desk, and shader permutations capped.
Illustrative. Cook and DDC work belongs to the effectiveness review.
−22%Streaming pool retuned and two duplicated texture sets removed. Gold marker is the platform ceiling.
Illustrative, from the fictional sample report.
These are worked examples from a fictional project, not client results. The sample reports show the format used to turn a capture into a decision.
Before kickoff
An outside review of the build reads to some engineers as an audit of their work. Worth defusing before it starts, not after.
Conversations with individual engineers are confidential from management. Nothing anyone says is attributed to them, in the report or in conversation. Where a finding can only be described in a way that identifies its source, it is aggregated until it cannot be, or raised with that person first and included only with their agreement.
The findings are about the code and the content, not about who wrote them. No individual is rated, no ranking is produced, and none of this is an input to a performance or headcount process. In practice the engineers are usually the ones who most want the review to happen — they have known about half of these findings for months.
Ask and you will get a short written note addressed to the team rather than to you, describing what is being looked at, what is not, and what happens to anything said in a conversation. Most leads send it before kickoff.
