I don't buy the C++ is faster that Python argument. It's just a driver
for a compiler! You could write it in Turing machine primitives and it
would be super fast on a modern computer. It's not computing the
strongly connected components of a terabyte sized graph.
The issue is start-up time. It takes longer to launch the python process than it does for the entire compilation and code generation process to happen on small C files at -O0.
I completely agree. The startup time for python was a huge problem for the *first* clang driver, which happened to be written about Python.
FWIW, Reed contacted me about this work back in May. I encouraged him to contribute to improving the main Clang driver, and he wasn't interested. It's perfectly fine for him to go off and do something different, but this work clearly isn't interesting to mainline clang development. I don't see why we're still discussing it
I didn't say that I'm not interested to fix this in mainline clang .
I needed something right away and it was not practical to try and sort out all of this in mainline clang in a timely fashion.
I fully understand that one sometimes has to do the "wrong" long-term thing to make a short-term deadline, and understand that you needed the driver to do something that the clang driver didn't already do.
However, for it to go into mainline clang, it has to be better at what the clang driver *already* does, or it is a regression. As compile times are very important for the project, any serious proposal to replace the existing driver with something written in python is a non-starter.
At this point I think it's better for me to continue my prototype in Python.
Sure, go for it. I just wanted to clear up apparent confusion where some people thought you were proposing it as a replacement for the existing driver.