As a xoogler who's wanted to use this and invest in it, I'm curious about the state it's in. Google has been investing in perfetto, this is different, but has some redundancy. It would would be nice to know this isn't abandonware.
Using some scripts/parsers to take DTrace/perf/Instruments/ETW
data and transfer it to perfetto was one of the most exciting moments of my performance engineering career. It’s such a powerful thing compared to every single other workflow I’ve ever used.
It just shows contention in a way that so hard to see otherwise.
If this tool packages some of that in an easier to use package it’s going to be a great tool for some.
You start with a trace event you care about. You see it’s too slow. The first step is that you see explicitly that it’s not because the code is slow, you constantly get descheduled because there are thread state indicators above your event.
Then you navigate to the CPU tracks find the thread(s) that were running instead of the one you care about and directly inspect their stacks. Sometimes almost nothing is running. Maybe contention is not on even on the CPU.
So the “parsing styles was slow” conclusion you would get from only looking at histograms turns into “parsing styles was slow because I couldn’t get my fonts and that was slow because IndexDB was hogging the hard drive on another process”
Edit: I should mention the user provided trace events are very important here. You get flow arrows really underlining task posting and IPC response as well as user interactions. Entry/Exit style uprobes on function are great but I found won’t get you all the way there on a large application.
Stadia was dead-on-arrival (regardless of any technical merits), the uncertainty, money and amount of work required on games leaves developers skittish about unreliable platforms (or companies). Especially with something as a new techonology like with streaming games where people were more or less rightfully concerned about latency.
All their product killings had already gotten someone to register the killedbygoogle.com domain on 2018-09-12 , that's a month before Google Stadia was even in closed beta. People were already joking about when they'd close Stadia when it was released.
Adding insult to injury, everyone saw the absolute fuckup with the Terraria developer. You have an indie developer (that iirc was _featured_ in the Stadia promotions) who loses his work Google accounts making it impossible to work and in frustration announces that the game is dead (apparently his account and the game were re-instated but after a month people had lost track and the image damage was done).
And yes, Google had some big-name contracts outside of just indies, but viability of a platform is always evaluated by it's entire scope (and iirc EA wasn't on board from day 1).
Google has a huge image issue with being humanly unreachable, we accepted with when Google was a cool perky upstart with a do-no-evil creed that hadn't messed up enough yet, but it's far harder to swallow from a big company that we know are only doing it's automated account management to save money (and is so insulated that it takes a _month_ to unfreeze an account of someone that is even supposed to be your partner!).
Idiocy was expecting game developers would blindly jump into GNU/Linux, Vulkan, with a stone age development experience versus what game console devkits and Windows look like.
I wasn't surprised given how bad Google Android talks at game conferences tend to be, so they put up with Google's lack of game development bones.
Android is only different because game developers don't have a option if they want to cover both top mobile platforms.
Android GDK is still a joke versus what Apple puts out, let alone Microsoft, Sony and Nintendo.
simply not true. Stadia had full integration into MSVS in build and debug flows. Even 'lets show a build to management' flows there were better than Windows (i was in shock myself). And for long time during Covid Stadia builds were the easiest way to get playtests up and running at home.
But I agree with your other point that investing into porting and Vulkan renderers was a huge waste of dev resources.
I found the Stadia developer experience to be pretty solid. The visual studio integration was top notch and worked, with a few minor exceptions, without a hitch. Having worked with all major gaming platforms to come out in the last two decades, Stadia was certainly not the worst.
Shortly before Stadia was ramped down, there was a talk about Stadia team starting the Stadia Porting Toolkit, as they weren't getting enough studios interested in porting their XBox/Windows engines into Stadia, versus what they would get out of GeForce Now and Cloud Game Pass.
While it certainly has helped to spread the spectrum of managed languages used across an OS stack, something that Microsoft failed at with Longhorn due to internal politics between DevDiv and WinDev, it has definitly plenty of warts, starting by the expectation to wait for the first set of bug fixes afer each "stable" SDK/IDE release, somehow all the previews, canary and beta are never enough.
Imho the thing that killed stadia was the pricing model. Buying games but not owning them outright* is a recipe for failure, especially for a company known for killing off services (and I say that as a xoogler with very mixed feelings). Stadia should have just had a monthly subscription fee.
*Yes, with DRM, copy protection, online only, etc, it's debatable whether anyone owns any game. But conventional game ownership or even steam style is still _more_ ownership than the stadia case.
They killed the user-facing product because by all accounts it was a flop. The tech is still there but they're pivoting to a game-streaming SaaS/middleware thing for B2B.
at least looks like they dropping support for windows
"Orbit's focus has shifted to the Linux version. Windows local profiling is currently only supported partially and major features, such as dynamic instrumentation, are not yet implemented. It is possible however to profile Linux executables from a Windows UI instance. For Windows local profiling, you can still use the released binaries, but please note that they are deprecated and mostly undocumented."
Does tracy support automatic function entry/exit (FEE) traces (i.e. all functions are automatically instrumented with a start/end)? The documentation seems to indicate traces are all manual which is pretty inconvenient. There are very few cases where you even need manual instrumentation if you have FEE data from my experience.
Can anyone suggest a good non-sampling profiler for low latency apps? The only one I can think of is https://github.com/morganstanley/Xpedite but it's not even clear that it is being maintained anymore.
VTunes can tell you the average time that functions take to run but which tools can highlight functions that very occasionally run a lot slower than normal?
Not if you are on macOS, the number of available profilers drops after every release.
Same with leak detectors, valgrind doesnt work, sanitizers don't work anymore (even if you compile your own clang).
At least in the specific case of Tracy, you can profile over the network. So, you instrument your OSX application, and it streams its data in realtime to your profiler viewer.
Though it's true that more advanced features require OS support (eg: showing how threads get moved amongst CPU cores, and so on).
Is there _any_ usable profiler on macOS? I've found Instruments to be straight-up useless (very slow, frequently gives just plain wrong results on larger projects) and pretty much every search I've tried just gives “use Instruments”.
Both address sanitizer and UB sanitizer work for me (macOS-13.6, Intel). You have to add a library search path and the appropriate `libclang_rt.*` library to your build.
Library search path is `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/1[4-9].[0-9].[0-9]/lib/darwin`.
Sadly there’s no one tool to rule them all. The only choice is to use the best tool for each platform.
Superluminal is far and away the best profiler imho.
Tracy is a great instrumented profiler. But damn do I love a good sampling profiler. Tracy can sample. But I had serious issues with it on one of my projects I could never get around.
According to the presentation video, it is a profiling tool used for Stadia Games ( https://www.youtube.com/watch?v=8V-EPBPGZPs ) that can adapt to Unity and Unreal Engine. Which seems to make sense as the original developer has experience developing on video games.
The main selling point of the tool is Dynamic instrumentation, which allows you to generate Flame charts without manual code annotation
(you pick functions that you are interested into, and the profiler adds a hook to these functions in order to log the entry+exit time).
