Compile time of Chromium and other questions #34

Closed
shimakazekai opened this Issue Feb 16, 2016 · 1 comment

Projects

None yet

2 participants

@shimakazekai

Hi,

I want to start contributing to chromium, (I am a beginner with regards to C++ and programming in general) and I read that the compile time can take a few hours and that's on a decent PC (and I have just an overclocked i5, 8gb ram, and no SSD), so I'm concerned that if each compilation will have to take hours then, how can you get anything done?

Also, I'm using visual studio and I read that chromium is using a different compiler, I read on your site that you debug with printfs, but to where does those printfs go? The chrome console? (I'm used to console applications)

Also, don't you ever need to step into the programs sometimes to follow the bug? How does Chromium devs debug and step into this huge project?

Thanks for doing this.
S

@notwaldorf
Owner

Oh boy, all of these are great questions. First, yay! 🎉 Welcome to Chromium! 🎉

This ended up being an enormous reply, so I broke it in sections. 🐳

Hardware

Most Chrome developers that work for Google have incredibly beefy machines under their desks, that build Chromium really, really fast. I had a Z620 with a buuunch of cores, and it was magical. Even then, a complete rebuild would be about 20-25 minutes. I've also successfully built Chromium on my laptop, which is a 2.3 GHz retina MBP with 16GB of RAM and a 256 GB SSD.

The official build instructions say that the minimum recommended setup is 4-8 cores and 16-32 GB of RAM are best. An SSD helps a ton. I think you should give your setup a try, and see what happens; worst case scenario, it will just take 10 hours. You'll also notice that just downloading the code will take a very long time -- there's like 10+ gigs of Chromium code, syncing all of it ain't a walk in the park 😅

Faster builds

A lot of "being productive" comes from tricks that make you rebuild less code:

  • enabling the component build (explained here) is a must -- this won't really make your initial build faster, but it will make incremental builds significantly faster.
  • not syncing and rebuilding master every day. I once ran some stats and found out that Chromium gets on average 160-ish commits a day -- that's a bunch of new code, which probably will touch a lot of headers, and will have to rebuild and link a ton of stuff. What I used to do for my patches is sync master once, at the beginning of me working on a branch, and working on that branch until you're done with your patch, without syncing master. Once the patch is almost ready to be uploaded, rebase master then (and probably resolve a bunch of merge conflicts). That way, while you're working, the only code that should change on your branch will be code that you write -- which again, should make incremental builds faster. This approach makes parallel branches a bit harder, but it will at least let you explore working on Chromium for a bit.

Edit: @nico just pointed out he has more tricks to make incremental builds super fast. His full answer is here, but the TL; DR is:

  • if you set disable_nacl=1, gyp will run 30% faster and your build will be ~15% faster
  • if you set fastbuild=1, your build will be faster, but you won't have full debug information
  • on OS X, Release builds are noticeably faster than Debug builds. Unsure about Windows, but I would suspect "probably yes"
  • if you set component=shared_library, incremental builds will be way way faster (like 10x as fast)

Debugging

Here's the instructions on debugging on Windows. I can't remember if printfs work on Windows anymore (they used to not, because the Windows command prompt is not actually a terminal; I mostly used a Mac, and there they definitely go to the console), but if they do, they would either go to the command prompt, or the chrome_debug.log file (the link should help you with that), or both.

I also sometimes used lldb (which is the llvm equivalent to gdb). I wrote a bunch of bare minimum instructions on how to use llvm for literally just setting breakpoints, stepping through code, and inspecting variables, which is usually what I need the most.

Hope this helps, and good luck!

@notwaldorf notwaldorf closed this Feb 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment