Jeff Webb
banner
jeffwebb.tech
Jeff Webb
@jeffwebb.tech
Staff Engineer @ Boss Fight Entertainment, formerly Harebrained Schemes

He/Him

If I say something it'll likely be about programming, performance, or video games

https://www.jeffwebb.tech/
Reposted by Jeff Webb
November 15, 2025 at 5:12 AM
A team I was on reduced the number of bone weights for lower end devices for adaptive perf.
November 10, 2025 at 10:08 PM
That's actually awesome and I didn't remember that.
November 10, 2025 at 9:50 PM
Oh, and I guess the easiest piece of perf related advice is that the things you *don't* do take zero time. Kick the clowns out of the car.
November 6, 2025 at 3:00 AM
That's it for my perf brain dump. Will I delete this now that it's out of my brain? Maybe! Who knows.
November 6, 2025 at 2:48 AM
I like to make it a CSV that I can import into a google sheet. This will let you generate neat perf graphs without too much trouble, and there are easy heat maps you can generate this way as well.
November 6, 2025 at 2:48 AM
"Telemetry is great (you can fake this with logs and timestamps)" This is what it says. If you *have* telemetry use it. If you're an indie, you can fake this by regularly logging out to a file your metrics with data like a timestamp, level, location, etc.
November 6, 2025 at 2:48 AM
This is a common misconception. Aside from rare cases, you won't immediately spot problems from opening a profiler sample. You need data over time to see how things are changing. Aggregate perf measurements are only understandable when placed next to other data over time.
November 6, 2025 at 2:47 AM
"Have reproducible (ideally automated) steps for getting it" You *need* a test plan. Our QA friends are underappreciated in what they bring to the table here. Run the same steps on the same devices in the same configuration regularly. Data without consistency is noise. You *need* consistency.
November 6, 2025 at 2:47 AM
This gets two posts. Always profile your code before you submit it to a main branch. Just take a look and see if it's reasonable at the very least. Make sure you run it with an expected number of objects/elements plus a buffer.
November 6, 2025 at 2:47 AM
For profiling, your engine likely has a built in profiler. If not, there are other options you can use. My favorite is Superluminal, though it's not free. Also, there are sampling vs instrumented profilers. They're good for different things, so use them both! I'll elaborate some other time.
November 6, 2025 at 2:46 AM
The metrics are just things you can log on screen or to a data log on regular intervals (CPU/GPU time, Frametime, number simulated objects, draw calls, etc). Save these out and figure out a way to plot them in a session/level/etc. Associate with change lists so you can see when they change!
November 6, 2025 at 2:46 AM
"Figure out what data you need" This comes down to two types in my mind. Generalized metrics and profiling (use the profiler!).
bsky.app/profile/flas...
November 6, 2025 at 2:46 AM
"Design your code for the hardware you will run on" Remember that "cache" thing? You'll want to learn about where things are stored in memory. Put things next to each other that will be operated on in order. Operate on groups. I recommend this video for learning more: www.youtube.com/watch?v=Wwku...
Intro to Data Oriented Design for Games
YouTube video by Nic Barker
www.youtube.com
November 6, 2025 at 2:45 AM
"Determine your perf goals." Simple, just describe what you want. What those are will determine how difficult it is
"I want to run at 60 FPS on my low end hardware."
"I want to support X enemies/players on screen"
"I want to move in a complex open world with no hitches or loading"
November 6, 2025 at 2:44 AM
For GPUs the similar level advice is to check your batches and pipeline states. You hear a lot of talk about LODs, vertex count, etc. These are nice and important, but breaking batches or having too many different shader variants are were most people are dying. Also, please prewarm your shaders.
November 6, 2025 at 2:44 AM
CPUs are not complicated at the level you need to understand them to get good perf. Understand the cache and how it relates to RAM. Memory reads/writes are likely your biggest cost, and doing this will save you so many headaches later.
November 6, 2025 at 2:43 AM
Let's expand those. "Pick your target hardware, understand it." What device are you running on? Every perf-conscious dev I know has 10 year old device somewhere at hand to see how things run. And understand it? Learn the basics of how CPUs and RAM work.
November 6, 2025 at 2:43 AM
(I frequently find that people will get prematurely defensive about their code when they talk to me, like they should have hand optimized assembly to be proud of it, but don't sweat "perfect" over "good enough." If you're making a turnbased card game in Godot, you likely aren't struggling for perf)
November 6, 2025 at 2:42 AM
- Pick your target hardware, understand it
- Determine your perf goals
- Design your code for the hardware you will run on
- Figure out what data you need
- Have reproducible (ideally automated) steps for getting it
- Telemetry is great (you can fake this with logs and timestamps)
November 6, 2025 at 2:42 AM