While clang is still in my experience faster than gcc, it turns out handling that last 5% correctly can knock a lot off your performance. Of course with terminals it might turn out you don’t need that last 5%, or you really can get all the way and keep the speed, but this isn’t the first project dedicated to making “the fastest terminal”.
Not sure how this got off terminals and on to compilers, but here we are.
Having written the profiler I used to optimize this (Sysprof), and a large portion of the OpenGL renderer that GTK uses, I know a thing or two about what code runs in the hot path from VTE. So I could target something that does enough of that to see what should be possible as a best case / upper bound.
That's why I'm fairly confident that adding the rest of the features that VTE has (which is one of the most comprehensive terminal emulator code bases out there) wouldn't affect this particular test case.
That said, I have no interest in doing that. I'd rather just go make VTE fast at drawing and call it a day. I have literally dozens of other projects in GNOME that require my time.
I hope you are right, and also someone else will pick this up -- I've just seen an awful lot of projects over the years that provide a huge speedup for 90-95% of the functionality of other products, and very few manage to keep the speedup once they hit full functionality.
Compilers could be faster, but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. In my opinion, not so for terminals: I'm pretty sure you could analyze the amount of time spent rendering in a terminal emulator and come to the conclusion that a lot of it is essentially wasted, with exception of a few more modern terminal emulators that considered this more deeply. This is in part due to the nature of the outputs of terminal emulators vs compilers; like for high throughput, it would be good if the terminal emulator spent as little time as possible processing things that won't ever actually make it to a frame. Compilers are mostly not interactive though, and don't have the luxury of deciding to simply not do something because nobody is looking.
I don’t think that there’s any evidence that this is true. In fact, the performance of the Rust compiler has continually improved over the last five years while _adding_ new features, and not by removing anything. <https://perf.rust-lang.org/dashboard.html>
All a C++ compiler needs to do to get similar results is to have a team that does nothing but performance work, and is actually rewarded for it.
Rust is different. It has a completely different design for translation units and modules that C++ can't adopt without hard breaking changes, due to e.g. the way its macro system works.
There are teams at all of Google, Microsoft, et al that spend time on C++ build performance. At this point, it's not even necessarily just about faster build times. Their builds could be measured in environmental impact at that scale.
[0]: https://www.gem5.org/project/2023/02/16/benchmarking-linkers...
Since VC++ modules support got good enough, that all my side projects only use modules.
A few breaking changes to the language have been made over the years (such as the introduction of async/await), resulting in several different editions of the language. The compiler supports all editions equally, and different crates can even be in different editions, even if they are linked into the same program. That means that code written for Rust 1.0 still works perfectly, and there is no need to update it to the latest edition in order to continue using it even in programs that are written in the latest edition.
For large C codebases, compile time is dominated by lexing and parsing, not optimization passes.
Headers have become too crufty; they tend to only grow over time, resulting in an amplification attack on the lexer and parser.
Lazy parsing is maybe interesting. There's a hazard related to the mangling of lambdas. Carbon has an interesting idea of not constructing an AST.
I think we also need tools to help us automate header refactoring.
It reminds me of the massive Fast kernel headers patchset by Ingo Molnar. I hope it got in. I don't know anything about it, just marvelled at the scope of it.
Imagine 30 years of headers. They tend to grow and grow and become a tangled mess.
Ingo's patch set did not.
I asked what was being done to automate this so that we wouldn't backslide.
I received no response.
That said, I think that work is fascinating. I have an intern starting Monday that's going to start research into automating this.