Mozilla 1.3 Alpha Released
Friday December 13th, 2002
Mozilla 1.3 Alpha is out! This release introduces shedloads of new Mail & Newsgroups features (including Bayesian spam classification, message views and improved filtering), a new Bookmarks Quick Search bar (similar to the one found in Phoenix) and support for the Back and Forward buttons on the IntelliMouse Explorer. There's also improvements to the DOM Inspector and lots of other bug fixes. However, remember that this is only an alpha release, so expect bugs.
#42 Re: Re: Re: Re:
Sunday December 15th, 2002 11:43 AM
You are replying to this message
>If I'm not mistaken, the reason IE loads so fast is due to pre-loading >during the OS bootup.
>>This is a myth. After you launch mozilla the first time, you lose this >>advantage and it still feels slower after that.
The poser said "the reason IE loads so fast is due to pre-loading". How is it a myth that initial startup for IE is affected by it's pre-loading? You're denying that IE improves startup by using already loaded libraries? The poster suggested that IE's startup was so fast because it saved a lot of time on initial launch by being pre-loaded and you responded that IE pre-loading improving IE's initial launch time is a myth. Am I reading that wrong?
Mozilla's quicklaunch demonstrates that if you've already got most of Mozilla in memory that it can be very competetive with IE at initial startup. On my range of PCs (from 500Mhz with 128 MB RAM to 2.2Ghz with 1GB of RAM and several in between) Mozilla's start time, using quicklaunch, and new window time is very competetive with IE6. IE has a slight advantage but over my full workday (and I use a browser a lot for my work) I probably close and start a browser between 10 and 20 times and I'd wager that IE's startup advantage would save me no more than about half a minute each day. I save at least several times that much time with just one of Mozilla's time-saving features - being able to load several pages as my start page. With my usage, IE is considerably slower to startup and become usable (in which I include loading start pages) because with IE I have to launch several windows, switch between them, and click a bookmark menuitem or toolbar link for each of my several start pages.
>>The real reason mozilla feels slower is the overhead of XUL. XUL is >>nearly as fast as native components. However, there are these >>barely noticeable delays that add up and the slight inconsistencies >>with the native behavior that users notice.
It's worth noting that IE browsers don't all use native widgets either. IE uses a special set of widgets in at least version 4 and 5 but they're darn close to the OS set so as to not be noticed by most users. With the creation of the nsITheme code, Mozilla's widgets are also getting very close and should continue to get even closer (at the same time MS is deviating even further from native. See recent releases of WMP).
>>There are a few moments I always notice Mozilla is slower than IE" >>going back and forth between pages. When you click back in mozilla, >>there is a few hundred millisecond delay (enough to notice). In IE >>the response is much quicker.
And this has what to do with XUL performance? I'm no engineer so I'm not an expert in these areas but I've been involved long enough with Mozilla to know the basic difference between issues of startup performance (time it takes to load the various modules like nspr, necko, jsengine, layout, xpcom, nss, dom, toolkit, etc. into memory + time it takes to render the initial interface and content) UI performance (UI widgets with performance tied to layout, style system, image libraries, dom, JS, etc) and back and forward performance (time it takes to pull data from the cache, fetch any necessary changes from the net, rebuild the dom, layout the page, etc.). I fail to see how your issue of back and forward performance is in any way related to your claims that "the real reason mozilla feels slower is the overhead of XUL" or how it has anything to do with the poster's comments about initial launch times. Back and forward performance could be improved with zero changes to XUL. One possible improvement could be to cache the entire dom of the page along with the page content and save the time it takes us to rebuild that DOM. I believe that Opera does something like this to improve their back perf. Most suggestions I've heard have everything to do with cache design or performance and nothing to do with XUL performance.
>>A similar delay can be observed when clicking links, scrolling, opening >>new windows, new tabs, etc. It's not so much the loss of time that gets >>annoying but the awareness that things slow down momentarily.
I don't see any significant slow down when creating new windows or tabs. Maybe my hardware (some of it more than several years old) is just good enough for this to not be a problem.
>>The mozilla developers have done a great job optimizing gecko (which >>also handles the XUL). The performance degredation used to be much >>worse. In fact, I find that the 1.2 and later versions of mozilla are noticeably >>faster than the 1.0 series. However, IE has been gaining weight. In windows >>XP there are all sorts of themes and animations slowing down the UI. I think >>this will become much less of an issue as gecko & hardware become faster.
I agree with all of that. I think it's also useful to compare the performance of our current technology with say M18 or M14 (on which Netscape 6 and NS6 PR1 were based, respectively) because so many people got their first impressions of Mozilla performance when they tried those corresponding Netscape releases. I did this back when we were getting ready to release 1.0 and while it wasn't a surprise to me the performance improvements were dramatic. I believe that 1.0 was sufficient for most hardware released in the last 5 years (about the time the 6th generation processors started to penetrate the market) and agree that 1.2 and beyond are noticeably more performant than 1.0. I also agree with you about hardware getting faster. My personal opinion is that if Mozilla was to ship as a default Browser on a new, say Dell, machine that users wouldn't have any significant problems with Mozilla's performance. All but the bottom of the budget PCs are coming with 2-3GHZ processors 256MB RAM or more and even the budget PCs are shipping with at least 128 MB RAM, not to mention that you can add .5GB of RAM for between $30 and $150 depending on your particular flavor.
Mozilla needs to continue to improve in performance. Phoenix has demonstrated some pretty significant startup and new window performance(as well as sidebar and other widgets). But raw speed isn't always the answer, at least not the only answer. A few simple examples can point out where real-world usage performance and raw speed measurements don't alway equate. My example above about being able to load several pages in tabs at startup is one. Another is page load where we have preferences for how fast gecko throws something up to the screen that trades off with how fast gecko finishes the complete load of the page. People who set this timeout to something really low or zero all seem to think that it's a huge improvement in pageload speed even though it can slow down the actual total pageload time significantly. A third example is pop-up controls. I'll bet that there's at least some tiny performance implication for by including this feature but the time it saves a user in dealing with annoying popups I think is a huge win in saving users not just aggrevation but _time_.
We need to be thinking about more than just these raw performance numbers because startup or pageload numbers may mask the real speed with which users are able to get things done in the browser. If we're not offering a tool that makes browsing a better and faster experience then people won't use it. I think we're on the right track with incrementally improving raw performance and at the same time adding features which help users accomplish their browsing tasks faster.