[HN Gopher] Tracy: A hybrid frame and sampling profiler for game...
___________________________________________________________________
Tracy: A hybrid frame and sampling profiler for games and other
applications
Author : pkkm
Score : 25 points
Date : 2023-01-28 18:18 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| noxa wrote:
| Having written similar tools like this in the past I pretty much
| exclusively use Tracy nowadays and let all my old stuff rot. The
| UI is snappy/fluid even with a tremendous amount of events,
| instrumentation is rich (zones/plots/memory tracking with timing,
| GPU events, logging, etc) and sampling is robust across all major
| platforms (Windows/Android/Linux/Mac) and the
| disassembly/analysis is as solid as most vendor tools. If wanting
| to integrate/use any tool like this I strongly recommend Tracy
| and then occasionally using vendor tooling where better (but
| platform/hardware limited). Having a single swiss-army knife perf
| tool makes it much easier for most of the team to learn and use
| it and leave the specialized knowledge of vendor tooling to those
| who need it.
|
| There's also superluminal (https://superluminal.eu/), but it's
| closed source/paid - wolfpld (the Tracy author) is responsive and
| there's a decent set of contributors so switching to a black box
| on a part of the engineering process that is designed to avoid
| black boxes isn't very enticing. It also is sketchy/misleading
| about saying things like "Superluminal is the only sampling
| profiler that displays the profiling data in a visual UI." which
| is a big turn-off for someone who's been using/building tools
| like that for decades :)
| Animats wrote:
| Tracy has been around for a while. It works well for Rust.
|
| It's intended for frame-oriented applications, where you're
| looking for bottlenecks which delay a frame. Unlike most
| profilers, where you're concerned about average time, Tracy is
| most useful when you're concerned about worst-case time. You can
| find the slowest frame and zoom way in to see what went wrong.
|
| The program has to be instrumented. You add
| profiling::finish_frame!()
|
| to be called once per frame. Around scopes of interest, you add
| profiling::scope!("Event");
|
| then run and look at the result, which is a zoomable timeline. If
| a profiling scope is using a lot of time, you go back in and add
| more "scope" calls around subsections of that scope. This gets
| you more rows on the profile graph and more detail about where
| time is going.
|
| It's more of a microscope than most profilers.
| blondin wrote:
| awesome name! crazy that no one (that i know of) never named a
| profiler that.
| IlGrigiore wrote:
| I have used Tracy to improve the performance of a latency
| sensitive application. The main advantage of this tool, in
| comparison to something like the Visual Studio profiler, is the
| fact that it can highlight the inter thread dependencies and
| synchronization between the threads. The other main feature, in
| my opinion, is the statistical tab that is associated to the
| recorded events: it can show the statistical distribution of the
| duration of all the invocations of functions and it allows to
| identify patterns in the performance of the application.
| Furthermore, a table can be used to sort the invocations of the
| functions and quickly jump to the point in time when the sample
| was recorded.
|
| Other notable tools that implement a functionality similar to
| what is provided by Tracy are Optick
| https://github.com/bombomby/optick and Intel VTune (sadly
| specific to only Intel processors) in the Threading analysis.
___________________________________________________________________
(page generated 2023-01-28 23:01 UTC)