Sebastian Schöner
@sschoener.bsky.social
Programming! - previously at Epic Games, Unity Technologies, Paradox Dev Studios
https://blog.s-schoener.com
https://blog.s-schoener.com
Every once in a while, I check the reviews on my games on Steam. It's always nice when a game finds the exact player it was made for. New review from July:
"We Love this game, it plays as advertised." (store.steampowered.com/app/1584170/...)
How I advertise it:
"We Love this game, it plays as advertised." (store.steampowered.com/app/1584170/...)
How I advertise it:
November 13, 2025 at 8:49 AM
Every once in a while, I check the reviews on my games on Steam. It's always nice when a game finds the exact player it was made for. New review from July:
"We Love this game, it plays as advertised." (store.steampowered.com/app/1584170/...)
How I advertise it:
"We Love this game, it plays as advertised." (store.steampowered.com/app/1584170/...)
How I advertise it:
Async, too much
blog.s-schoener.com/2025-09-22-a...
blog.s-schoener.com/2025-09-22-a...
September 23, 2025 at 8:52 AM
Async, too much
blog.s-schoener.com/2025-09-22-a...
blog.s-schoener.com/2025-09-22-a...
Here is what we're waiting for. For a moment I considered turning one of my monitors by 90° to capture the entire callstack, but I opted for some screenshot surgery instead (screenshot from @superluminal.eu):
March 13, 2025 at 12:42 PM
Here is what we're waiting for. For a moment I considered turning one of my monitors by 90° to capture the entire callstack, but I opted for some screenshot surgery instead (screenshot from @superluminal.eu):
If you know the Windows x64 calling conventions really well, you probably already have alarm clocks ringing in your head. I had to re-read the assembly not once, not twice, but three times before I figured out what is happening:
January 17, 2025 at 10:44 AM
If you know the Windows x64 calling conventions really well, you probably already have alarm clocks ringing in your head. I had to re-read the assembly not once, not twice, but three times before I figured out what is happening:
Today I installed a platform's SDK. At the end, it offers a link to "learn more about what's new." It opens an HTML help viewer. Everything freezes. I record a short trace: all string processing. 4 hours later, it is still stuck. Am I the first person to click that button?
December 18, 2024 at 6:26 PM
Today I installed a platform's SDK. At the end, it offers a link to "learn more about what's new." It opens an HTML help viewer. Everything freezes. I record a short trace: all string processing. 4 hours later, it is still stuck. Am I the first person to click that button?
I think you can actually do a unity build. Screenshot below: One entry point takes function pointers to all the things you want to call, then puts them into a shared static. Then later on you call the function pointers manually. Only one entry point for Burst compilation :)
December 14, 2024 at 9:03 PM
I think you can actually do a unity build. Screenshot below: One entry point takes function pointers to all the things you want to call, then puts them into a shared static. Then later on you call the function pointers manually. Only one entry point for Burst compilation :)
We're at 1s now (vs. 2.4s) and a large chunk of that is a codepath (RenderPreviews) that I have looked at last time, and those optimizations aren't included here yet.
November 20, 2024 at 7:08 PM
We're at 1s now (vs. 2.4s) and a large chunk of that is a codepath (RenderPreviews) that I have looked at last time, and those optimizations aren't included here yet.
So what are we going to do about the remaining ~750ms? Most of this is UI rebuilding, and we can make that faster as well.
November 20, 2024 at 7:08 PM
So what are we going to do about the remaining ~750ms? Most of this is UI rebuilding, and we can make that faster as well.
The problem again immediately disappears and we saved 400ms. Nice.
November 20, 2024 at 7:08 PM
The problem again immediately disappears and we saved 400ms. Nice.
Why is this so expensive? Well, it turns out that for every single node in a "group", we go through the entire graph and look for that group. Again, there is a simple fix: we can precompute that info if needed. Note that there is already an option for that.
November 20, 2024 at 7:08 PM
Why is this so expensive? Well, it turns out that for every single node in a "group", we go through the entire graph and look for that group. Again, there is a simple fix: we can precompute that info if needed. Note that there is already an option for that.
Now for the second worst part: re-adding the nodes. It spends 660ms doing that, of which 430ms are going into enumerating some UI stuff.
November 20, 2024 at 7:08 PM
Now for the second worst part: re-adding the nodes. It spends 660ms doing that, of which 430ms are going into enumerating some UI stuff.
Let's stop doing that. It's unnecessary in this case because it "reevaluates activity", but we're ripping the entire graph out anyway. There's already a flag for that, and changing 7 characters (add ", false") makes this thing disappear:
November 20, 2024 at 7:08 PM
Let's stop doing that. It's unnecessary in this case because it "reevaluates activity", but we're ripping the entire graph out anyway. There's already a flag for that, and changing 7 characters (add ", false") makes this thing disappear:
The first low-hanging fruit is to look at the ~480ms in ReplaceWith, which throws out the old graph and puts in the newly de-serialized graph. It removes everything, then re-adds it. We remove edges one-by-one, and every edge removal walks the graph.
November 20, 2024 at 7:08 PM
The first low-hanging fruit is to look at the ~480ms in ReplaceWith, which throws out the old graph and puts in the newly de-serialized graph. It removes everything, then re-adds it. We remove edges one-by-one, and every edge removal walks the graph.
Now to the actual thing I want to measure. Here is me undoing adding an edge divider in the HDRP Lit graph. Takes 2.4s. Roughly 500ms were previously discussed (red box). And then there's ~500ms of GUI update that comes on top (right side).
November 20, 2024 at 7:08 PM
Now to the actual thing I want to measure. Here is me undoing adding an edge divider in the HDRP Lit graph. Takes 2.4s. Roughly 500ms were previously discussed (red box). And then there's ~500ms of GUI update that comes on top (right side).
I accidentally left Unity running in the background with shadergraph open, and when I tried to switch back, Unity froze: the frames had reached a duration of 31s. You can see where it went back to the foreground again and unfroze (red marker). But I digress.
November 20, 2024 at 7:08 PM
I accidentally left Unity running in the background with shadergraph open, and when I tried to switch back, Unity froze: the frames had reached a duration of 31s. You can see where it went back to the foreground again and unfroze (red marker). But I digress.
Second, I noticed while measuring this that once I put Unity into the background, CPU usage goes up sharply. Something about rendering changes, which probably makes the number of GPU fences grow wildly, and we're getting slower every frame.
November 20, 2024 at 7:08 PM
Second, I noticed while measuring this that once I put Unity into the background, CPU usage goes up sharply. Something about rendering changes, which probably makes the number of GPU fences grow wildly, and we're getting slower every frame.
I've taken a look at all active GoogleDrive processes, and they don't seem to be doing anything. Let's try something else. We can use Process Monitor to get some clues. This here looks incredibly relevant:
November 18, 2024 at 3:41 PM
I've taken a look at all active GoogleDrive processes, and they don't seem to be doing anything. Let's try something else. We can use Process Monitor to get some clues. This here looks incredibly relevant:
There are two big stalls here. They are both suspiciously close to 10s, which makes me think that "SleepConditionVariableSRW" is called with a 10s timeout here. That's a long timeout!
November 18, 2024 at 3:41 PM
There are two big stalls here. They are both suspiciously close to 10s, which makes me think that "SleepConditionVariableSRW" is called with a 10s timeout here. That's a long timeout!
I am trying to get to the old context menu in the explorer in Windows 11. When you have the new menu open, you have to click "Show more options." This reliably freezes for 20s. Why? Let's take a look in @superluminal.eu.
November 18, 2024 at 3:41 PM
I am trying to get to the old context menu in the explorer in Windows 11. When you have the new menu open, you have to click "Show more options." This reliably freezes for 20s. Why? Let's take a look in @superluminal.eu.
Where does this leave us after 2 days? We're at ~185ms now (~170ms for the graph update) vs. 1.3s. Still bad (it's still Mono), but noticeably faster. Other operations are still painfully slow (undo! - next week?) and it at least feels much better in comparison.
November 17, 2024 at 3:48 PM
Where does this leave us after 2 days? We're at ~185ms now (~170ms for the graph update) vs. 1.3s. Still bad (it's still Mono), but noticeably faster. Other operations are still painfully slow (undo! - next week?) and it at least feels much better in comparison.
I'm no shader compiler myself, so my empathy here might be limited, but I think I would rather compile 4MB instead of 16MB of source. (4MB still feels like a lot!) Sure enough, this makes the shader compiler preprocessing about 4x faster.
November 17, 2024 at 3:48 PM
I'm no shader compiler myself, so my empathy here might be limited, but I think I would rather compile 4MB instead of 16MB of source. (4MB still feels like a lot!) Sure enough, this makes the shader compiler preprocessing about 4x faster.
I'd hope that dead-code-elimination would ensure that the unused calculations get purged, but this still leaves the question of shader compile times and struct fields. That's a question for another day, and not what I set out to do this time.
November 17, 2024 at 3:48 PM
I'd hope that dead-code-elimination would ensure that the unused calculations get purged, but this still leaves the question of shader compile times and struct fields. That's a question for another day, and not what I set out to do this time.
I have tried to look at the compiled shader code to understand if this affects codegen, but Unity's button for that just crashes things: Instead of 102 variants, it compiles tens of thousands of them and then runs out of memory while loading them all into memory. Sigh.
November 17, 2024 at 3:48 PM
I have tried to look at the compiled shader code to understand if this affects codegen, but Unity's button for that just crashes things: Instead of 102 variants, it compiles tens of thousands of them and then runs out of memory while loading them all into memory. Sigh.
Here is the shader that is generated for the "HDRP Lit" graph from the samples (opened in Unity 6 without changes). Note that all the checks for permutations are identical and cover all 32 permutations found in this graph. That's exactly the problem here!
November 17, 2024 at 3:48 PM
Here is the shader that is generated for the "HDRP Lit" graph from the samples (opened in Unity 6 without changes). Note that all the checks for permutations are identical and cover all 32 permutations found in this graph. That's exactly the problem here!
Then I found a thing that just made emit a deep "oh no." Really, going over all permutations and doing a graph search? Reality is a bit more nuanced but also more absurd yet, as I will explain.
November 17, 2024 at 3:48 PM
Then I found a thing that just made emit a deep "oh no." Really, going over all permutations and doing a graph search? Reality is a bit more nuanced but also more absurd yet, as I will explain.