Remotery

There's a kazillion tools out there. Here's a few off the top of my head to get started. RAD Game Tools Telemetry - http://www.radgametools.com/telemetry.htm Superluminal - https://superluminal.eu/features/ Remotery - https://github.com/Celtoys/Remotery Visual Studio's built-in profiler is an ok sampling profiler. It doesn't give you a nice multi-thread view which is a huge advantage to a span based profiler. MTuner is quite nice for debugging memory usage. Which is another gaping hole in the Rust ecosystem. https://github.com/milostosic/mtuner Lots of tools generate data in a format viewable by the Chrome trace viewer. I think Chrome's tracer viewer is not great. Maybe someday someone will create a viewer for the format that's good. I get cranky when large traces don't render at 60fps. Web-based viewers are almost all very very slow and

>> Interesting stuff, is that really a thing? To maintain 30FPS you must finish a frame in 33ms (1000ms/30). To maintain 60FPS you must finish a frame in 16ms. Some of the VR literature I've read has recommended 90FPS or higher to combat nausea - 11ms. A millisecond could easily be 1/10th of your entire frame budget for the whole game's per-frame processing time, to say nothing of individual subsystems. At least we have multiple cores, but some stuff must run on the main thread... > Also, rad game tools is a company that makes very useful tools for profiling. arcin is of course referring to Telemetry[1] here, a wonderful tool for generating explicitly annotated flamegraphs that I've helped integrate into multiple codebases at different jobs. Engine-custom[2] tooling is also common, where you're seeing scopes measure in microseconds.

Well, I have integrated Remotery, not what I was looking for but pretty cool. I have made a bunch of feature requests for it which would bring it more in line with other profilers: https://github.com/Celtoys/Remotery/issues/47

I wrote an HTTP server (https://github.com/tom-seddon/yhs) with pretty much exactly this use case in mind. (This influenced the main unusual thing about it: it doesn't use threads, the idea being that when your function is called in response to an HTTP request, you're less likely to have to do anything special before modifying values as requested.) The code is mostly complete, and should be usable as-is, but I never ended up using it in anger. My quick and dirty stopgap solution at the time was some on-screen (on the iPhone) widgets, and people seemed to prefer that in the end, because it meant they didn't need a computer/second iPhone/etc. So I never rolled out an HTTP-based equivalent. If I were doing it again, I probably wouldn't bother with a full(ish) HTTP implementation - I'd support only WebSockets. Then write the Javascript client