TRtranspute·Jul 27, 2024Submission
uftrace: Function graph tracer for C/C++/Rust/Python
2 points · Open discussionnamhyung
uftrace
C2016–2024
namhyung / uftrace
uftrace
Function graph tracer for C/C++/Rust/Python
5Distinct people
6Mentions
0Explicit recommenders
3.5KGitHub stars
What to know before exploring
What it is
Function graph tracer for C/C++/Rust/Python
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year6 dated mentions
Observed mentions: 2016-10-16 19:52:00 UTC to 2024-07-27 17:35:02 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
6 sourcesUftrace: Userspace Function-Graph Tracer
6 points · Open discussionUftrace: A function graph tracer for C/C++ userspace programs
2 points · Open discussionThe uftrace [1] tool is gold for counting function calls (and more), and I don't think it's that well known. It's relatively new.
I used 4 or 5 performance tools to look at the performance of Oil shell, and uftrace was one of the most important ones.
I hope to write a blog post about it soon. The overall results were very good -- Oil is now faster than bash despite doing more parsing by design -- though the biggest win was translating the code to C++ from Python :)
So it's unusual, but after translation, uftrace was a winner, and I used it largely by counting function calls and allocations, not measuring timing. Although you can use it in many different ways.
Oil's Parser is 160x to 200x Faster Than It Was 2 Years Ago
http://www.oilshell.org/blog/2020/01/parser-benchmarks.html
Another lesson is that aside from the big difference in ex
Read the rest
ecution speed, tools for measuring C++ performance are just way better than those for Python. Debugging tools are also better. Of course I still avoid C++ for most problems because of build times, headers, memory management, library style smorgasbord, etc.
[1] https://github.com/namhyung/uftrace
Off the top of my head:
- Count the lines of code with find | wc, get a sense for what's there, and what language it's written in. The biggest file in the project is usually worth a look -- it is often where the "meat" is. Read the function names.
- Use the program. grep for strings that appear in the UI in the source code. That's a good place to start reading. Read function names.
- strace the program. What system calls does it make when?
ltrace is also sometimes useful, although it also gives a ton of output.
- Look at header files. Understanding data structures is often easier than understanding code.
- Look at commit logs. Those are hidden "comments". And reading diffs can be easier than reading code.
- Do a "log" or "blame" on the file. How has it evolved?
- Start reading main(). This often reveals something about the s
Read the rest
tructure of the program. Even just finding main() in many programs is a good exercise :) Sometimes it's a little hard to find.
- Make sure to build it. And if you can, look at the build system. How is it put together? Most build systems are pretty darn unreadable. I don't really know how to read autoconf, and GNU make is tough too. Forget about cmake :) But sometimes this can help.
I haven't gotten that far with this, but I tried uftrace recently and like it:
https://github.com/namhyung/uftrace
You can think of it like a dtrace that knows about every function in a C or C++ program.
-----
I want to try some kind of code explorer thing. I saw this in a CppCon video and on HN:
https://www.sourcetrail.com/
And older ones like:
https://www.sourceinsight.com/
But somehow I get by with Unix tools. I think this is because I feel like building the project in a way to accomodate the source browsers might be a big pain.
Counterpoint: I think the hardest part of understanding a project is usually the build system :-) I don't have too much of a problem with reading C, C++, Python, or (sometimes) JS code. Volume is always a problem, but I can read a specific function pretty easily. But the build system is where things get ugly, in my experience.
Also, reading multi-threaded code requires some special consideration. grepping for every place that threads are started is a good idea.