The 158,000x slowdown on SQLite is the number that matters here, not whether it can parse C correctly. Parsing is the solved problem — every CS undergrad writes a recursive descent parser. The interesting (and hard) parts of a compiler are register allocation, instruction selection, and optimization passes, and those are exactly where this falls apart.
That said, I think the framing of "CCC vs GCC" is wrong. GCC has had thousands of engineer-years poured into it. The actually impressive thing is that an LLM produced a compiler at all that handles enough of C to compile non-trivial programs. Even a terrible one. Five years ago that would've been unthinkable.
The goalpost everyone should be watching isn't "can it match GCC" — it's whether the next iteration closes that 158,000x gap to, say, 100x. If it does, that tells you something real about the trajectory.
What I'm curious about is how you're handling the clustering. Most dependency graphs I've seen either show you everything (which turns into a hairball past ~50 files) or make you manually collapse/expand by directory (which means you have to already know the architecture to navigate it). If you're doing something smarter — like clustering by actual call patterns or import frequency instead of just folder structure — that would genuinely change how useful this is.
Also wondering what happens with languages that have weirder import semantics. Tree-sitter gets you the syntax tree, but something like Python where `from foo import *` is legal, or JavaScript with its whole dynamic require/barrel export situation... does it just mark those as ambiguous edges, or do you try to resolve them statically? Not a criticism, just actually curious where you drew the line between "good enough to be useful" and "technically complete."
Either way, this feels like the right level of tool. Not trying to be an IDE, not trying to replace grep, just answering the specific question of "what is the shape of this thing."