Slashdot Mirror
How Maintainable Is the Firefox Codebase?
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.
>> A number of modules, namely, accessible, browser and security, frequently appear among the most complex modules. Further investigation may be helpful in identifying why that is the case.
Does this guy know what Firefox is?
It finds that 11% of files in Firefox are highly interconnected
Figures like this would be more useful if they were put in context. What is a "normal" level for connectedness? What is the level for the Linux kernel, or for GCC? Compared to other similar sized projects, is 11% good or bad?
MSE says this bugger is present on the site: http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=Trojan%3AJS%2FIframeRef.K&threatid=2147679863
You know that you don't have to load things in tabs if you don't want to, right? And I highly doubt that you're going to have any meaningful performance improvements by loading up different windows. Plugins are there for every browser and the worst offenders tend to be things like Flash which aren't always easily avoided. Extentions themselves aren't usually a problem if you don't install badly behaving ones. And many of them do actually help out with performance, noscript anybody?
and tomorrow we'll count the lines of code and spew more meh
I am wondering how this stacks up to a project like WebKit/Blink, as well as seeing that project against the original KHTML. Sure it is a renderer/HTML layout/JavaScript engine only, and won't contain the browser chrome like Firefox, but I think it would be interesting to look at.
Many people have also suggested that WebKit is easier to embed into various different environments (more so than Gecko) and that it has been able to evolve faster mainly due to the code base being cleaner, and I wonder if this holds true when looking at it from a complexity standpoint, or is it more complex but simply laid out better and in a way that is easier to understand?
cat
According to recent comments (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
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.
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.
... that have no meaning at all.
Impacting 8 files on average would be horrible... for a project with 8 files. But how many is that relative to the size of Firefox?
11% of files in Firefox are highly interconnected... but how does that compare to other projects of similar scope?
The one value in that summary that had any meaning at all was the comment that the percentage of interconnected files "went up significantly following version 3.0". That at least has some relative measure we can use as a base.
Don't blame us, blame the marketers and SEO people.
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, 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.