-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracy-based expr evaluation profiler #9967
base: master
Are you sure you want to change the base?
Conversation
This is a first quick-and-dirty way to get the tracy integration up and running without losing my sanity trying to bend the autotools setup to work with it. Introducing a tracy submodule, injecting the required headers from here, building the TracyClient.cpp file to get the actual tracy client library.
We're leveraging the ZoneTransientN macro to send dynamic strings containing the expression type, file and position in that file of the expression Nix is currently evaluating. We had to add a new showExprType method to the Expr class to get a const string containing the name of an expression.
Two expressions evaluations seem to be contained in the EvalState class. Tracing them as well through a new macro.
Tracing the primops with Tracy as well. Not sure it really worth the overhead, but we still can revisit this decision later if we realize primops are not that important perf-wise.
please don't add even more junk to each individual expr |
The idea is to hide the profiler behind a autotools feature flag making these macros no-op. I won't undraft this until the runtime cost of it when the feature flag is disabled is 0.
Performance-aside, this sounds like a better approach. Would you have any link (code, documentation) that would set me on track to do this? |
have a look at the |
Well, this was as painful as expected. Introducing a proper autotool-based tracy build. I don't think this is the right approach, but hey, it works. Tracy is not distributing any pkg-config file, so we had to fallback to a more "manual" method to propagate the headers path. Instead of having a plain enable/disable flag, we send the path to the tracy /public subfolder (~= $out in the Tracy Nix derivation). The flake Nixpkgs is currently pointing to 23.05. The tracy derivation was only building the visualizer, not the client library back then. We introduce a 23.11 Nixpkgs and build its Tracy derivation with the 23.05 toolchain to go around some glibc ABI incompatibilities. Kudos to Mic92 for the help for the flake bit. Co-authored-by: Jörg Thalheim <[email protected]>
671739c
to
3ea4870
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-02-28-nix-team-meeting-129/40499/1 |
Small status update: Here's a tracy dirty hack to workaround the segfaults: wolfpld/tracy@c9addab My current plan is to spend some time using the tool to see if it's worthwhile. If it is, I'll spend more time debugging this tracy race condition and improve the integration to the Nix codebase. No ETA, $work has been pretty intense for the last 2 weeks, I do this on my sparetime. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/nix-flamegraph-or-profiling-tool/33333/14 |
The tracy patch does not appear to fix the segfault for me, it still crashes when I dare to move my cursor over its window. I've opened a trace of a NixOS eval and am on a relatively recent nixos-unstable. |
Hmm,
I may be able to help if you can post the stacktrace.
|
coredumpctl info
|
This is a WIP profiler for the Nix code itself, not the cpp Nix evaluator. The goal is to provide some tooling to improve the Nixpkgs evaluation performance.
This is a WIP Nix profiler using Tracy. The idea is to trace the evaluation of the expression atoms to figure out what is expensive. We are roughly tracing the thunk evaluation. Nix is a lazy language, I think this is what makes most sense.
Short demo video
TODO before Undrafting
This is not ready yet. We need to fix at least those two issues before undrafting this PR.
HELP WELCOME :)
Elephant in the room: tracy SEGFAULTS!!!!!!!!!
We have those weird "???" frames in Tracy. Hovering them with the mouse segfault the viewer.
Removing the line and the column in the position pretty printer makes them go away. Sadly, removing the column and position from the trace also makes the profiler useless :D
There's something very wrong in our client code, but I couldn't figure out what. For now. This is the first item on my TODO list.
Profiler performance
There's room for improvement. Random datapoint, with the profiler enabled:
Without the profiler:
That's not a surprise, I did not make any effort here, each profiler macro is generating at least 3 allocations.
We should run perf on this and see what's wrong.
Move out the trace macros from the eval call sites
See #9967 (comment)
Is this useful/refine design?
We should spend some time using this profiler. Can we spot issues with it? Can we remove some useless noise from the traces?
There's no magic trick here, we need to spend time using the tool to improve it.
How to test?
nix build github:picnoir/nix/pic/tracy-profiler
nix-shell -p tracy
. Then, either lauch the graphical profiler to watch the capture in real time (tracy
), either record the run through the headless capture utility (capture -o capture.tracy
).nix-instantiate
utility you built in step 2. EG../result/bin/nix-instantiate -A nixosTests.pleroma path-to/nixpkgs/
???
with your mouse to prevent segfaults. Scroll-wheel to zoom/unzoom, left click to move the trace.Priorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.