There are a number of people on various Mozilla forums that seem to be under the impression that any performance problems in Mozilla are caused by XUL. I'm not sure why they have this impression. I suspect that they see the various text files used and assume that they must take a long time to load and parse. I suspect, as with many people that complain about performance or resource issues, that they don't actually understand how other systems work. Here is a description of what happens when a window is opened in Mozilla:

XUL, scripts and other files are read from the JAR archive files in Mozilla's chrome directory. They are interpreted and compiled and a post-processed version is stored into a binary file (the fastload file) and saved to disk. This step is only done the first time you ever open the window -- the binary file is used from then on.

Since that step is not repeated again, the following is what happens every time afterwards:

What happens when a window is opened in Mozilla

When a window needs to be opened, the widget definitions and the layout of the window is loaded from the binary fastload file. The UI toolkit constructs objects for each item from the fastload file. Those objects, along with the toolkit, determine how to place themselves on the window. The UI toolkit calls drawing commands (line drawing, image drawing, etc...) to draw the elements to the screen.

Now let's look at what happens in other GUI systems, such as Windows 3.0 and every version after it, on all versions of the Macintosh, in Visual Basic, and Delphi, and in many other UI toolkits.

Click this button and note the differences in the paragraph above.

Note the similarities?

It should also be noted that Mac OS X applications also store their UI's in various external files, some of which are plain text files (or XML files), which get interpreted when needed. And how many people have you seen complaining about how slow Safari or Chimera are?

There are no "extra layers" as some are fond of mentioning. XUL widgets are read from a file as other systems do and are placed and drawn using low-level drawing functions. Where are these extra layers these XUL detractors often mention? I don't see them.

The truth is, there is no architectural flaw in the design of XUL that would make it slow, as it doesn't really operate any differently from other GUI toolkits or native UI systems. Thus, if it is the XUL component that causes any performance issues, they should be fixable over time, since the issue isn't a by-design issue, but an implementation specific one.

What I mean is that one could construct a different implementation of XUL that used all of the same file formats, but faster, since XUL's design is not fundamentally different from other UI toolkits in terms of how it loads content.

Here is a test to see if Mozilla takes too long to start:

  • Count the number of seconds Mozilla takes to start up. Multiply by the number of times you might start it in a month.
  • Count the number of seconds (or minutes) it took you to write lengthy rants about Mozilla's performance over a month long period on the newsgroups.

If the second value is greater, you obviously have lots of time. If the first value is greater than you have realized that 5 seconds of your life each day isn't worth getting stressed out about.