It looks really nice. I wonder if it’d be possible to break it down even further by somehow instrumenting the actual processes and including their execution flame graphs as part of the chart. That would expose a ton of extra information about the large gaps of “inactivity”.
I made a real-time C/C++/Rust build visualizer
71–80 of 91 posts
Re: I made a real-time C/C++/Rust build visualizer
#72If you use the Visual C++ compiler on Windows, vcperf is worth a look: https://github.com/microsoft/vcperf - comes with VS2022, or you can build from github. I've used it with projects generated by UBT and CMake. I can't remember if it provides any info that'd let you assess the quality of build parallelism, but it does have some compiler front end info which is pretty straightforward to read. Particularly expensive…
Also Incredibuild. The free version is probably good enough to visualize your build and see any bottlenecks.
Re: I made a real-time C/C++/Rust build visualizer
#73This looks awesome.
I've used clang's -ftime-trace option in the past and that's also really good. It's a pity gcc has nothing similar.
Re: I made a real-time C/C++/Rust build visualizer
#74Looks like a general `fork()` visualizer to me. Which is great!
I like that the name reflects its broad usefulness
Re: I made a real-time C/C++/Rust build visualizer
#75Does it work with cmake?
A CMake build is used as an example in the blog post. It's literally just visualizing all spawned processes, so it will work for anything that spawns subprocesses to do the build.
Re: I made a real-time C/C++/Rust build visualizer
#76I love the visualization, I think it's great information and will be very helpful to whoever uses it. I would think about a different name. Often names are either meant to be funny or just unique nonsense but something short and elegantly descriptive (like BuildViz etc.) can go a long way to making it seem more legitimate and being more widely used.
Thanks CyberDildoNics!
I'm interested to try, but don't get what that early access signup is about. Where is the email address going to show up? Can I use a temp mail?
Re: I made a real-time C/C++/Rust build visualizer
#77Earlier quoted context omitted.
Thanks CyberDildoNics!
I'm interested to try, but don't get what that early access signup is about. Where is the email address going to show up? Can I use a temp mail?
I used the term "early access" when I should've used "private beta". The sign up is just for me to have an email addresses to send the private beta when the next update goes out, and I'll follow up for feedback. Nothing sinister is happening.
Re: I made a real-time C/C++/Rust build visualizer
#78Would love to have our team try this out (we have some ridiculous rust builds).
Re: I made a real-time C/C++/Rust build visualizer
#79Earlier quoted context omitted.
I'm interested to try, but don't get what that early access signup is about. Where is the email address going to show up? Can I use a temp mail?
I used the term "early access" when I should've used "private beta". The sign up is just for me to have an email addresses to send the private beta when the next update goes out, and I'll follow up for feedback. Nothing sinister is happening.
> to send the private beta when the next update goes out
Meaning I only can try the software after sign up, or did I miss the obvious repo link?
What language is this project written in, what build system does it use itself?
I just don't feel comfortable pasting my email address into a Google site. I can use a temp mail, but I will loose access to it in a few minutes/hours, so I don't know if that would annoy you.
What kind of times do you expect in the form, serial or parallel build time? What kind of file do you want to be modified. When I modify main.c, basically nothing gets rebuild, when I modify the central header file, it will be like a total rebuild. Can you clarify that in the form?
Re: I made a real-time C/C++/Rust build visualizer
#80I am extremely interested in this. I am stuck in an environment with CMake, GCC and Unix Make (no clang, no ninja) and getting detailed information about WHY the build is taking so long is nearly impossible. It's also a bit of a messy build with steps like copying a bunch of files from the source into the build folder. Multiple languages (C, C++, Fortran, Python), custom cmake steps, etc. If this tool can handle that…
I wrote a little GCC plugin for compile time tracing/profiling, if that's something you're interested in: https://github.com/royjacobson/externis
I just went ahead and tried it out :)
I can get it to work for some sub-sets of our project, but for quite a bit of it I get the following error:
cc1: error: cannot load plugin /opt/rh/gcc-toolset-13/root/usr/lib/gcc/x86_64-redhat-linux/13/plugin/externis.so: /opt/rh/gcc-toolset-13/root/usr/lib/gcc/x86_64-redhat-linux/13/plugin/externis.so: undefined symbol: _Z14decl_as_stringP9tree_nodei
I suspect this is because these are C or Fortran sub-projects. I'm looking for some clean way to tell Cmake to apply externis to all the C++ only subprojects if possible. I'll see what I can come up with.
I'd also like to know, if multiple GCC commands end up pointing to the same trace.json, especially in a parallel build, will externis automagically ensure that it doesn't step over itself?