Hacker News new | ask | show | jobs
by singular 4586 days ago
I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-)

I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal - fast cycle development, then on deploy build something fast. I think gc go vs. gccgo is potentially a model for this :-)

2 comments

Firefox build times are much faster than that. My MacBook Pro can build Firefox in 12 minutes, but other people can build everything in less than 8 minutes! :)

https://groups.google.com/d/msg/mozilla.dev.platform/HdXdNdf...

Everything should happen in under 3 seconds. Once you get past that threshold, you get a qualitative change in development style.
Wow. I'm really impressed with that. I'm looking at >1hr on a mid-2012 Macbook Pro Retina for Chromium.
Mozilla is always looking for new contributors. Think how much more productive you could be with such fast Firefox builds! ;)

* Videos on how to download, build, and debug Firefox code: http://www.codefirefox.com/

* Good first bugs: http://www.joshmatthews.net/bugsahoy/?cpp=1&unowned=1

I'm trying to contribute to the Chromium project and believe me, when you're waiting over an hour to compile 1 day's worth of patches, you begin to dream of faster compile speeds :-)

But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation time is IMO overstated by Go proponents.

Besides that, e.g. JRebel and DCEVM provide true hotswapping. So, generally, developing e.g. a web service in Java does not have a visible compile and deploy cycle at all.

I think having some sort of optional 'really fast compile' vs. 'optimal performance' build is the ideal

Why not have really fast compiles and JIT compilation when needed to make it fast (Java, C#, F#) or just JIT compilation (JavaScript). Of course, the trade-off is that you have to carry around a VM, but the JVMs and JS VMS are ubiquitous.

> But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation time is IMO overstated by Go proponents.

Actually, chromium's ninja [0] build setup [1] is really awesome, and does what it can with incremental building, but it's obviously limited in what it can do, it doesn't seem to take very much to trigger a very big rebuild. It's a definite help though.

[0]:http://martine.github.io/ninja/ [1]:https://code.google.com/p/chromium/wiki/NinjaBuild

(I don't seem to be able to reply to your comment directly)

danieldk 8 minutes ago | link

>> As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.

> And I am reacting to your grandparent, who was talking about compilation.

I'm fairly certain that that slow compile time is a combination of `compile + link` and the linking is probably a big part of the equation as well, just like it is in C and Go.

Absolutely, I should have said 'build' rather than 'compile'. It's both compilation and linking.
> But that is mostly a problem because incremental compiling in C++ is difficult for well-known reasons. Incremental compiling is well-supported in many other languages (e.g. Java) and is usually very fast. So, the issue of compilation time is IMO overstated by Go proponents.

As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.

As I've already said to someone else. This is about linking, not compilation. The rest of your comment is irrelevant to this discussion.

And I am reacting to your grandparent, who was talking about compilation.