Mike Hommey, a Firefox developer, blogs about Firefox builds, memory allocators and build performance.
Commenters cite his posts on Python and glibc allocator behavior and on Firefox's roughly 18% speedup from a build optimization.
(I work at Mozilla, but not on the VCS tooling, or this transition)
To give a bit of additional context here, since the link doesn't have any:
The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.
In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.
For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".
It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration…
These builds still have distribution-specific in-built API keys for some of the built-in services such as Google Safebrowsing, Google Location Services and Mozilla Location Services. See [1], [2], [3], [4], [5] and [6] for details and examples.
Additionally, upon first launch of Firefox, a unique client identifier is created, and this is sent to Mozilla by default probably before you get a chance to disable telemetry features within the preferences dialogs. See [2], [7], [8] and [9].
As these privacy impacting features are enabled by default, before first launch of Firefox on Linux, you should disable these third party and telemetry features and also lock down other security and privacy settings. See [10] and [11] for the method of doing so, and an example user.js that contains decent documentation on well over a 100+ recommended configuration changes to make Firefox more respectful of privacy and security. If you don't reconfigure a user.js before first launch, at least the "New Profile" event will be notified to Mozilla with the unique client ID after a delay of only 30 minutes from creation of the first Firefox profile[9] (first launch).
[1] https://glandium.org/blog/?p=3923
[2] https://github.com/mozilla/gecko-dev/blob/HEAD/build/moz.configure/keyfiles.configure
[3] resource://gre/modules/URLFormatter.jsm (use within Firefox URI bar)
[4] resource://gre/modules/AppConstants.jsm (use within Firefox URI bar)
[5]…
For those who haven't explored LLVM, it's an incredibly powerful technology and rather approachable for getting started with.
A few of my favorite LLVM discoveries:
- If you want to build Clang (LLVM C/C++ Compiler), it's really simple to pull down and build with little external development tooling (only a compiler and CMake). Shown here [0].
- You can pull LLVM/Clang master and use that for a "bleeding-edge" toolchain with a high degree of stability. [0].
- Clang is used to compile Chromium and Firefox on all platforms. Both have seen great performance gains from Clang's link time optimization. [1] [2]
- Klee is built on LLVM infrastructure and is used for automatic generation of test cases. [3] See some of their papers for how powerful their results are.
- Clang can now produce ABI compatible binaries with MSVC and has support for the Visual Studio debugger. [4]
- Lots of interesting research projects leveraging LLVM [5]
[0] https://www.youtube.com/watch?v=uZI_Qla4pNA
[1] http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html
[2] https://glandium.org/blog/?p=3888
[3] https://klee.github.io
[4] http://blog.llvm.org/2017/08/llvm-on-windows-now-supports-pdb-debug.html
[5] https://scholar.google.com/scholar?as_ylo=2017&q=LLVM&hl=en&as_sdt=0,33
> what do you think of .net core?
Not the parent commenter, but... This is not relevant; .NET Core is a managed environment. If your needs dictate it, then it's a very good choice.
> that's the only native-code-generating compiler for windows other than mingw-64 (and proprietary compilers)
clang also generates native Windows code. You can even set clang to automatically target Windows and expect the Windows SDK by running `clang-cl`. You of course will need a Windows SDK and MSVC C/C++ runtime mounted on a case-insensitive filesystem, like the Firefox guys have done[1].
[1]: https://glandium.org/blog/?p=4020
Supporting Windows is often a pain (although in this case Rust hides a lot of that pain, honestly), but the main driver of the original sccache implementation was not Windows support, but the ability to share the compilation cache across our many ephemeral build machines. My colleague Mike Hommey (who wrote the first implemenation) has some nice graphs demonstrating this in his original blog posts on the topic:
https://glandium.org/blog/?p=3079
Python uses its own allocator for small sizes (below 512 bytes if I remember correctly). I've had a similar problem to yours. See https://glandium.org/blog/?p=3698 and the followup
https://glandium.org/blog/?p=3723 . I have a glibc bug open about the issue https://sourceware.org/bugzilla/show_bug.cgi?id=23416 .