GJgjvc·Oct 7, 2026Submission
1 points · Open discussionplasma-umass
coz
C2014–2026
plasma-umass / coz
coz
Coz: Causal Profiling
24Distinct people
26Mentions
1Explicit recommenders
4.6KGitHub stars
What to know before exploring
What it is
Coz: Causal Profiling
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I haven't had a chance to mess around with it much, but the coz-profiler [1] uses basically the same idea, but the other way around (i.e., slow down everything else to get a…
jaybosamiya used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
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 year26 dated mentions
Observed mentions: 2014-12-10 14:14:20 UTC to 2026-10-07 09:36:40 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
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 |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 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 | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 2 | 0 |
What Hacker News says
26 sourcesCoz: Causal profiling that measures optimization potential
1 points · Open discussionOne of my previous struggles has been profilers blaming whatever code is the first bit of code to force some memory into cache.
We devs could take turns and claim to have improved our own code by a huge margin simply by rearranging the order of calls so ours was not first. Then pass the baton; global performance utterly unchanged, everyone gets to "optimize" their own code.
Something like https://github.com/plasma-umass/coz
might be the way forward.
https://www.youtube.com/watch?v=r-TLSBdHe1A
In Can we know whether a profiler is accurate?from the youtube description:
"Large language models are achieving state-of-the-art results across a wide variety of domains, eclipsing past work in well-studied areas like auto-completion. I argue that they also presage a "Cambrian explosion"—a wave of radically new AI-powered software development tools that will make all our lives easier. I propose a paradigm for how we can best rethink existing tools to leverage a combination of LLMs and PL technologies like static and dynamic analysis. This approach promises to evolve our software tools far beyond their current capacities, including profilers that suggest optimizations, debuggers that identify and propose fixes using real-world knowledge, coverage analyzers that synthesize new tests, compilers that propose fixes for compile-time errors, and data analysis frameworks that analyze your d
Read the rest
ata."
Some links from the presentation
- https://github.com/plasma-umass#plasma-projects
- https://github.com/stephenfreund/flowco
Plasma - projects:
- RightTyper: Automatically annotates your Python code with high-quality types
- https://github.com/righttyper/righttyper
- Scalene: A state-of-the-art CPU+GPU+memory profiler for Python, with AI-powered optimization suggestions GitHub stars
- https://github.com/plasma-umass/scalene
- Coz: A causal profiler that tells you where to optimize your code (C/C++/Rust/Swift/Java)
- https://github.com/plasma-umass/coz
- CSrankings: Ranks the world's CS departments
- https://csrankings.org/
- CoverUp: Automatically generates high-coverage tests
- https://github.com/plasma-umass/coverup
- Slipcover: Nearly zero-overhead code coverage analysis for Python
- https://github.com/plasma-umass/slipcover
- ChatDBG: AI-assisted debugging in lldb, gdb, and pdb. Uses AI to answer 'why'
- https://github.com/plasma-umass/ChatDBG
- CWhy: ("See why") Explains and suggests fixes for C/C++/Rust compiler error messages.
- https://github.com/plasma-umass/CWhy
- Commentator: Automatically comments Python code, adding docstrings and type annotations
- https://github.com/plasma-umass/commentator
- SQLwrite: SQLite3 with natural language to SQL, recommends indexes to optimize queries
- https://github.com/plasma-umass/sqlwrite
Obviously from the paths it's Linux. Running on Arch.
Looks to be an open issue FWIW: https://github.com/plasma-umass/coz/issues/180
The project also sees very little meaningful maintenance activity which leads me to believe it failed to get traction for whatever reason / the authors aren't really focused on it (probably grants ran out & they moved onto other things).
In Coz: Causal ProfilingCoz: Finding code that counts with causal profiling
2 points · Open discussionNobody should do benchmarking like this anymore.
Memory layout of your code has such a big impact on performance on modern computers that measuring performance without removing that variable leads to wild goose chases, where you think you improved something, but in reality you incidentally got the compiler to move the code around a bit.
Emery Berger has an excelent talk on this [1], and a causal profiler that they developed called Coz[2].
Branch miss-predicts might be somewhat invariant to that, but still, one of the main points of the talk is that people do too much eyeball statistics, mistaking the variance of the underlying stochastic process with actual signal.
Coz is pretty trivial to set up with Zig too.
1. https://m.youtube.com/watch?v=r-TLSBdHe1A
2. https://github.com/plasma-umass/coz
In Poop: Performance Optimizer Observation PlatformCoz: Finding Code That Counts with Causal Profiling
3 points · Open discussionAsk HN: Has anyone used Coz for casual profiling?
I was thinking of doing some kernel profiling, and stumbled upon this interesting repo: https://github.com/plasma-umass/coz
I'm pretty intrigued by the concept, and was wondering if anyone here tried out Coz.
1 points · Open discussionFor the impatient, the profiler is available at https://github.com/plasma-umass/coz
In Show HN: 10-40% faster LZMA decoder using x86 CMOVccTake a look at coz the causal profiler: https://github.com/plasma-umass/coz
From what I know this is the closest project that fits your description.
In Tip: Time-Proportional Instruction Profiling [pdf]"benchmarks always tell you if there's a problem and exactly where it is, and squash any unneeded discussion." Unfortunately, always is too strong of a word. Cache eviction in one parts can cause memory stalls on another part, indirection in the caller can prevent speculation. Type erasure can prevent inlining resulting in the called function being blamed for problem in the caller.
Your problem might not even be CPU, if it's contention related, or timing related, overloaded queues, not pushing back at the right places, io bound, the bottleneck is work which is queued and executed elsewhere...
Causal profiling is a technique which is relevant specifically because profiling can miss the forest for the trees: https://github.com/plasma-umass/coz
It's really easy to write a benchmark which measures a different scenario from what your applicati
Read the rest
on is doing. A classic example might be benchmarking a hashmap in a loop when that hashmap is usually used when cold.
I definitely agree about directing efforts to where you can make an impact and guiding that through measurement, but benchmarks can miss that there's a problem and blame the wrong part of the application.
If the difference is large enough, ms vs hours, you'd have to really screw up methodology to get the wrong result (I've done it almost that badly before).
Try getting them to watch this talk by Emery Berger:
https://www.youtube.com/watch?v=r-TLSBdHe1A
And who knows, maybe they'd even be interested in using coz afterwards:
https://github.com/plasma-umass/coz
In Prefix Trees in ActionCoz: Finding Code That Counts with Causal Profiling
2 points · Open discussionShowing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.