How Maintainable Is the Firefox Codebase? 127
An anonymous reader writes "A report released this morning looks at the maintainability level of the Firefox codebase through five measures of architectural complexity. It finds that 11% of files in Firefox are highly interconnected, a value that went up significantly following version 3.0 and that making a change to a randomly selected file can, on average, directly impact eight files and indirectly impact over 1,400 files. All the data is made available and the report comes with an interactive Web-based exploratory tool."
The complexity exploration tool is pretty neat.
Got a trojan warning (Score:5, Informative)
Re:So? (Score:4, Informative)
It's crucial to know the distribution of that 11%. If they were all located in one area, it might be as you say, But if the 11% was comprised of a few files in each major module, then that'd be bad.
You want the bulk of your program doing the actual work to look like a tree. You don't want the bulk of your program to look like a mesh (graph). This is especially true of your core components.
LibXUL on Win32 approaching 4GB memory limit (Score:5, Informative)
According to recent comments [mozillazine.org] (continued on the next day's thread), the win32 compiler that Mozilla use is approaching the 4GB limit, after which LibXUL (which Firefox depends upon) will no longer compile.
It's currently at 3.5GB, and at the current rate, will reach the limit in approximately 6 months: Chart of memory usage of LibXUL during last 90 days [mozilla.org]
While I think that Servo will produce a more decentralised design than Gecko and XUL, the memory limit will be reached well before that. With Windows XP support ending next year, Mozilla should consider migrating to x64 as soon as reasonably possible, keeping x32, but focusing on stripping large and extraneous code above new features.
Um, you forgot to go AC when you trolled. (Score:4, Informative)
Really? The version number thing again? Hasn't that been played out yet? Incidentally, 3.0 is not even close to when they moved to a rapid release cycle.
The code base was not designed for concurrency (Score:5, Informative)
It's a real problem. The Firefox dev team gave up on running add-ons in a separate process (the "electrolysis" project) because the code base was too single-thread oriented. Remember, some of the code dates back to Netscape. There's talk of reviving that project now, [internetnews.com] but it's mostly talk and meetings.)
Refitting concurrency tends to be very hard and the result tends to be ugly. You get something like Windows 3.x or MacOS 6/7, where easy things are complicated for the wrong reasons.
Re:LibXUL on Win32 approaching 4GB memory limit (Score:5, Informative)
I'm a Firefox developer.
This is slightly inaccurate. We aren't running out of memory to link Firefox, we're running out of memory to run Profile-Guided Optimization (PGO) on Firefox.
PGO looks at what is actually executed during a given workload and optimizes based on that. It can be a pretty big win — 30% in some workloads —so we work pretty hard to keep it going.
Unfortunately, PGO needs to have not only all the code, but all the intermediate representations and other metadata about the code in memory at one time. (That's why we're running out of memory.)
Unfortunately, MSVC doesn't support producing a 32-bit binary using their 64-bit compiler.
(FWIW, Chrome has *always* been too big to use PGO.)