Hacker News new | ask | show | jobs
by gp7 3301 days ago
Compile time is a huge factor in maintainability!
2 comments

It's really not. BUCK and other build systems make compile lightning fast, and when you have a complex multithreaded bug because of sloppy optimization, faster compiles won't help.
This is exactly the sort of situation where fast compiles often do help, in my view! Debugging is one case where speed of progress can depend on build time, because you need to run the code after each change to see what effect it had and to decide what to do next.
Optimised code is occasionally so cryptic that you'll just waste a few hours figuring out what it does, which basically nullifies the effect of faster compile time.
> when you have a complex multithreaded bug because of sloppy optimization, faster compiles won't help.

Code that cryptic is exactly the kind of code I often want to modify with more instrumentation, logging, sanity checks, test cases, etcetera. "The problem seems to go away if I do X" isn't a real solution, but it can be a great hint at times, especially if you've got a small and relevant resulting difference in the disassembly. "X asserts right at the site of the fundamental bug" is handing you the solution on a gold platter. Slow build times discourage adding these things, and refactoring systems to be harder to misuse. If it takes hours to rebuild your full setup, nobody but the crazy people (such as myself) will touch common headers to preemptively add such things to make the codebase more maintainable.

Even if it's not helping you in the instant, it's helping you in the long run.

> BUCK and other build systems make compile lightning fast

It sounds like you have compile times under control wherever you are. I'm happy for you - and perhaps a little envious ;).

BUCK won't magically solve multi-minute link times. Full builds of a lot of things I've worked on require zipped, compressed, and cryptographically signed packages of gigabytes (which must then be verified, uncompressed, and unpackaged to test) - BUCK et all can't solve this terribly well either. Distributed build systems are pretty magical about solving embarrassingly parallel compiles, although even for compilation it doesn't help me too much when I'm on the bleeding edge doing hours worth of builds just to test a reasonable subset of our build configurations - maxing out a 6-core - before rolling out the latest SDKs and compilers to the rest of the build farm and my coworkers.

There are various tricks one can employ to help keep build/deploy/test cycle times in check for the common case - faster linkers like gold, distributed build systems like BUCK, dev builds which stream unsigned assets from host computers instead of from a package, etc. - but someone has to do the work of setting those all up.

This doesn't address the argument that sacrificing other factors of maintainability for faster compile times can hurt you in the long run