3 ms·
> For small compiles, the Go compiler was blazingly fast; on a large synthetic codebase (700 files), it was three times slower than clang compiling C. This rea
by SeanDav 14y ago
> For small compiles, the Go compiler was blazingly fast; on a large synthetic codebase (700 files), it was three times slower than clang compiling C.
This really stood out for me and seems to make a mockery of Go compile times for larger programs and perhaps more real-world situations.
- rogpeppe1 14y agoIf you've got a single package with 700 files (I'm pretty sure that's what he was testing), you're doing something wrong.
- aaronblohowiak 14y agoThe author had everything in one package. The package is the real compilation unit. The author claimed that this is the only way to use go because you can't have circular deps. Well, this is where structurally-typed interfaces come in to play -- you shouldn't have a circular dependency, it is just that your interfaces need to be compatible. For instance, each of the parts of the standard library is its own package... there is no circular dep on the "reader" interface, things just implement Read() and it "just works" (and is enforced by the compiler at link time.) Having 700 files in one package is an abuse of api.
- commentzorro 14y agoIt seems like it's a valid test of the compiler's speed as long as the C tests were done similarly. For real world situation who cares if it takes 300ms to compile instead of 100ms. But why not test with something the compilers have to work at?