Mozilla 1.0 Not Ready for Prime Time -- Close but No Cigar and No Brass Ring!
A Quick Look at Mozilla 1.0 Browser-Suite Performance -- Speed, Stability, and Memory Hogging
Mike Angelo -- 18 June 2002 (c)
What we found in our informal, quick, testing is that AOL-Netscape's Mozilla 1.0 is a memory hog, it eats up system resources, it is noticeably sluggish unless you are using a fairly fast computer with ample RAM, and it can cause system crashes and application lock-ups.
The good news is that for the most part, AOL-Netscape's Mozilla 1.0 poor performance is not all that noticeable on faster computers with lots of RAM. How well the operating system upon which Mozilla is run handles memory and task allocations also will impact upon how noticeable are Mozilla's performance problems.
How AOL-Netscape's Mozilla 1.0 performance problems affect your user-experience depends on the operating system, CPU speed, and physical RAM size of your computer. It also depends on how you use and work with your computer and on how you go about surfing the Web.
Some people will experience no noticeable performance problems at all with the Mozilla 1.0 browser suite and therefore will be very happy with Mozilla 1.0. Others will notice Mozilla 1.0's performance problems and be very annoyed by them.
The cross-platform (XP) Mozilla browser-suite software is designed to run on several operating system platforms including, inter alia, the BSD, Linux, Macintosh, Microsoft Windows, OS/2, Sun, and several UNIX platforms. Source code is available if you want to custom compile your own Mozilla builds.
The Performance Logjam Is the Mozilla Application Programming Framework (APF)
In part, some of Mozilla 1.0's performance problems come about because of the way the Mozilla developers chose to make Mozilla a cross-platform (XP) software product. The Mozilla developers did not elect to compile the Mozilla 1.0 browser-suite for each platform upon which it runs. That leads to some of the Mozilla 1.0 browser-suite's performance problems. Here's how and why.
It is somewhat complicated and conceptually looks something like this:
Simply put, the practical concept of the Mozilla 1.0 Application Programming Framework (APF) is that the Mozilla APF is custom compiled for each operating system (OS) upon which it runs. Then one can write an application, such as the Mozilla or Netscape 6/7 browser-suites, that runs on top of the Mozilla APF. That way, an application software developer does not have to port code from OS to OS in order to have a cross-platform application -- because the Mozilla APF does the job of running the same application code on each OS.
The Mozilla APF is pretty darn handy for application software developers. They can write a Mozilla-based application one-time and it will run on any computer upon which the Mozilla Application Programming Framework can run -- without any need to port code. (Wrtite once, run on many, or WORM if you like.)
However, there is a price to pay for the convenience from which developers benefit by writing programs that run upon the Mozilla APF. The Mozilla APF layer eats up system resources, slows down application execution speeds, and adds it own set of bugs, annoyances, and stability problems to the software applications that run upon the Mozilla APF. Additionally, it's likely that some of the overly-long time it takes to start the Mozilla browser-suite is due to the extra time it takes to load the Mozilla APF. More about that elsewhere and in an upcoming MozillaQuest Magazine article about the Mozilla Application Programming Framework.
If you would like to get into the details of the Mozilla Application Programming Framework, take a look at Part II: The Many Faces of Mozilla -- A Preview Look at the Mozilla Application Programming Framework and Essential XUL Programming by Vaughn Bullard, Kevin T. Smith, and Michael C. Daconta -- links in the Resources section at the end of this article. Unfortunately, there have been lots of changes to the Mozilla APF since Essential XUL Programming was written. So, some of the material in Essential XUL Programming is outdated. However, it still is a very good book to read if you want to learn the Mozilla APF and XUL concepts.
Our Mozilla-Skinning series articles also will provide some more information and detail on how this Mozilla Application Programming Framework stuff works. As with Essential XUL Programming, there have been lots of changes to the Mozilla APF since our Mozilla-Skinning series was written, too. So, some of the material in our Mozilla-Skinning series also is outdated. However, those articles still are a very good source for learning about the Mozilla APF and XUL basic concepts.
Back to the Mozilla 1.0 Browser-Suite
Mozilla 1.0 is pretty much the same as Mozilla 1.0-RC3. That final Mozilla 1.0 release candidate was placed on the Mozilla Organization public FTP server on 23 May 02, just ten days before the Mozilla 1.0 final release. Additionally, the final Mozilla 1.0 Test Builds were placed on the Mozilla Organization FTP server with dates ranging from 29 May 2002 through 31 May 2002. For most all intents and purposes, those final Mozilla 1.0 test builds were essentially the Mozilla 1.0 final release builds.
Even before the official Mozilla 1.0 release on 5 June 02, we already were taking Windows and Linux Mozilla 1.0-RC3 (release candidate 3) and Mozilla 1.0 final test builds for quick spins as part of our on-going evaluation of the Mozilla browser-suite software. Today's discussion of Mozilla 1.0 performance is based upon informal evaluations using those Mozilla 1.0-RC3 and Mozilla 1.0 final test builds, plus the 5 June 02 Mozilla 1.0 final-release builds.
Essentially, the Mozilla browser suite includes:
Among the most notable features of the Mozilla browser-suite are its:
We examine the Mozilla 1.0 browser-suite features, some Mozilla 1.0 annoyances and bugs issues, and take a closer look at its component modules elsewhere. In this article we focus on Mozilla 1.0's performance -- particularly for the browser and e-mail modules.
Mozilla Performance Issues
Early on, the Mozilla browser-suite suffered from major memory hogging, big-time memory release troubles, sluggish speed, system crashes, application lock-ups, and other performance problems. Although these sorts of problems still exist in Mozilla 1.0, there has been substantial improvement.
Overall performance in Mozilla 1.0 branch test builds and final release builds so far seems decent -- particularly on faster machines, with lots of RAM, that far exceed Mozilla 1.0's minimum system requirements. However, on slower machines that are at or not much above Mozilla 1.0 minimum system requirements, Mozilla 1.0 tends to be somewhat sluggish -- although faster than it was in the Mozilla 0.9.x milestone series. On Windows 98 SE, Mozilla 1.0 seems to run a little faster and more smoothly than did some earlier Mozilla 1.0 release candidates.
The minimum Mozilla 1.0 system requirements for Linux and Windows PCs are a 233-MHz processor (CPU) and 64-MB RAM. For the Macintosh PowerPC, minimum Mozilla 1.0 system requirements are a 266-MHz processor (CPU) and 64-MB RAM.
The default Mozilla 1.0 disk cache setting is 50-MB. If you do much Web surfing, Mozilla 1.0 is going to be adding and deleting cached Web-page files to your hard-drive frequently. So, it is likely that regular hard-drive defragmentation (MS Windows) will help with Mozilla performance.
In these informal tests, three Mozilla windows were opened with about a dozen or so window tabs opened in each Mozilla window. Initially, this would bring the Free Resources down to about 30%. Reloading the pages from time to time is what pulled the Free Resources all the way down to about 5% to 10% levels.
We also experienced some system crashes with the Mozilla 1.0 branch test builds and the Mozilla 1.0 final release build we used. Our suspicion is that Mozilla pulled the free memory levels down so low that crashes ensued due to low free memory. This suspicion is bolstered by several observations of Free Resources dropping down to 0% just prior to application lock-ups or system crashes.
If your computer use is rather light and your computer has a fast CPU with lots of RAM, you likely will not notice Mozilla 1.0's heavy memory consumption. Even if your computer use is somewhat heavy but your Web surfing is rather light, you likely will not notice Mozilla 1.0's heavy memory consumption or experience annoying collateral damage caused by excessive memory-consumption.
However, if your computer use is on the heavy side and you are a heavy-duty Web surfer to boot, you might notice Mozilla 1.0's heavy memory consumption and experience its annoying collateral damage. You also are more likely to notice Mozilla 1.0's heavy memory consumption and experience its annoying collateral damage if you are using an operating system such as the Windows 9.x series, which does not handle memory usage and application crashes well. You are less likely to experience the Mozilla memory and related crash problems with operating systems such as Linux or Windows 2K, which do a better job of managing system resources and application failures.
You should not have to put up with memory problems. These memory problems are yet another reason why Mozilla 1.0 is premature and not ready for prime time.
We will be running more formal memory tests on the final Mozilla 1.0 builds in a bit and will let you know the results when we get them. Stay tuned.
Despite the more than 500 open (unfixed) crash bugs in Mozilla, we normally, very seldom, experience a crash or application lock-up with the Mozilla browser-suite. However, we did notice an increase in crashes when testing some recent Mozilla 1.0-RC3 branch builds. The Mozilla 1.0-RC3 release-build and Mozilla 1.0 final build did not result in any crashes -- other than those resulting from Mozilla sucking up all the memory, which led to crashes.
At the time Mozilla 1.0-RC1 was released there were 533 crash bugs listed in Mozilla's Bugzilla bug-tracking database, 561 crash bugs listed when Mozilla 1.0-RC2 was released, and 585 crash bugs listed when Mozilla 1.0-RC3 was released. The crash bugs count is up to 615 open crash bugs today. Additionally there were nearly 150 open dataloss bugs listed in the Mozilla bug-tracking database, Bugzilla, today.
Earlier today, there were 25,012 open, new, assigned, and reopened bugs listed in Mozilla's Bugzilla database. Additionally, there are more than 4,400 open bugs listed in Mozilla's Bugzilla that have not yet been triaged. The total targeted open-bug count now is up to more than 12,622 bugs.
For more information about the Mozilla 1.0 bug-related problems, please see our companion article, A Quick Look at Some Mozilla 1.0 Browser-Suite Annoyances, Bugs, And Issues. Bug 81446 is an interesting bug report about Mozilla memory leak problems, which is an open bug at press time. Link in the Resources section on Page 3.
It's too soon to tell just how crash-prone Mozilla 1.0 is. Hopefully, it will not be crash-prone.
Copyright 2000-2002 -- MozillaQuest -- Brodheadsville, Pa..USA -- All Rights Reserved