Ritesh Oedayrajsingh Varma

Great post!

Including a sneak peek of a certain profiler on a platform that is very much not Windows ;-)

Speeding up the Unreal Editor launch by … not opening 5500 files? In my last article I wrote about some tooltip optimization to reduce the start time of the Unreal Editor by 2-5 seconds. Turns out people do really care about their editor start time. So much that …

It's understandable that Unreal needs to touch a lot of files when starting the editor. But what if I told you that >5500 of those files are not needed for the editor to start at all and are just adding seconds to the editor launch time?
(Fix included!)
#u5 #gamedev
larstofus.com/2025/09/27/s...

to be fair, you could have seen this coming from the “runs inside the terminal” as if that is something positive :p

Nice investigation! Sampling profilers > instrumenting profilers when you need to see what’s happening in code you *didn’t* write. Great example of the right tool for the job!

Profiling without Source code – how I diagnosed Trackmania stuttering A very common side effect of working as a programmer is the constant frustration of not having source code access to all the software you use. Bugs, problems or missing features in your own work ca…

My new blog post is there, and it's a bit different from usual: Fixing stutters in your own code is hard enough, but this time I try to fix performance issues in a closed-source game. No source code or debug symbols, but a lot of guesswork. larstofus.com/2025/07/27/p...
#gamedev
#Trackmania

Days since I've had to waste time debugging obscure issues caused by Linux's deranged shared library model: 0

"Nice that you're linking to a static library, but there's a shared lib loaded with the same symbol name in it, so I'm gonna use that one instead, ok?"

tfw you're collateral damage in the Great AI Wars

This was a great example of "how hard can it be?". Well, 4 days of full-time work fighting with Qt, that's how hard.

So glad you like it! ;-)

It turns out when you’re writing code that runs on each sample interval to collect stacks, you don’t have a lot of time if you’re targeting high sampling rates :-)

We've been micro-optimizing our eBPF code, and it reminds me of the SPU era a bit. The compiler/JIT is so basic that old tricks are useful again. Regular C turns into atrocious ASM, but writing C like it's ASM fixes it. I'm kinda loving it.

It's all stuff like this (before/after):

Solved it by the ancient tradition of Just Reading The Code.

Turns out continuously taking the RCU lock by inserting thousands of elements into a BPF_MAP_TYPE_LRU_HASH from within a NMI is Not Good for your system.

Rolled our own (simpler) version directly in eBPF.

How does one diagnose the entire Linux system locking up when using a particular eBPF data structure? Are there any post-mortem logs to look at? dmesg is only about the current session.

Asking for a friend.

In our case we’re looking at optimizing the perf of a single program, so an overview of which programs are running and how much time they cost is not that useful; we want to know which of the thousands of lines of code in *our* programs we need to focus on :-)

And of course, it is as tedious as instrumentation-based profiling always is.

Currently investigating & optimizing the perf of our eBPF-based capturing code, but there's no perf tooling for eBPF. So instead, we're profiling with manual instrumentation like savages. Ironically the very thing we originally set out to eliminate with Superluminal.

Hell, I'm a developer, and most of the time I just give up when confronted with this crap.

> visit website
> notice it isn't working
> open devtools
> 36 errors

I sometimes wonder how non-developers are supposed to use the internet nowadays. Are they just perpetually in a state of brokenness with no idea how to escape it, accepting this as 'normal'?

I haven’t used it on Windows so I don’t know if it’s any good, but my hope is currently for the Linux version of the RAD debugger (eventually). It can hardly be worse than the current options, so there’s that.

One thing people really like about Superluminal is that it Just Works, and we’re trying hard to get that same experience on Linux.

But this platform sometimes really feels like it’s actively fighting against anything “just working” and it would really prefer you Do The Work tyvm.

You’re one of today’s lucky 10000!

Though I am sad you went with the clearly inferior BC 😛

fwiw, we switched to mimalloc a few releases ago (and yes, it made a huge difference in qt perf), but we ran into allocator related crashes on Windows on Arm devices. Switched it back to the default allocator. I doubt that platform matters to you, but thought I’d mention.

Oof. Not wrong tho😂

*cracks knuckles*

*starts writing Yet Another String Parser for Yet Another Commandline Tool*

Yeah, what David said, but substitute Araxis for BC instead :-) You’re missing out with just the p4 tools; it’s not just about diffing changes.

Yeah, there’s nothing “wrong” with it, I just can’t get used to it. It’s fine for smallish diffs, but as soon as anything more structural is going on I can’t read it anymore with those big hatched blocks.

Funnily enough BC was the tool I started with and used to swear by, but I just cannot anymore.

Often find myself shelving on Linux and unshelving on Windows just to be able to use Araxis to review a change. Sigh.

The thing I perhaps miss the most while developing on Linux, besides obviously a good debugger, is Araxis Merge. I've been using Beyond Compare since we started on Linux support, and I just *cannot* get used to it. The diff view is just completely unparseable to my brain.

1) what

EINVAL, the "something went wrong" of the Linux kernel.

What went wrong? Who knows, read the source!

Oh it is the first one, wifi/audio not working is just expected behavior. I would never bother debugging that, would just google for the magic commandline to fix it :P

And will do!