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

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 :-)

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.

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

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.

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😂

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.