Three Monkeys, Three Typewriters, Two Days

February 20, 2004

Darin's string changes

Darin has more or less finished landing his string changes on the trunk. The upshot is:

  1. Pageload time went down by about 2-3%.
  2. Startup time went down by about 7-8%.
  3. Window open time went down by about 3-4%.
  4. Codesize went down by several hundred kilobytes (ranging from about 150kB to 500kB or so depending on the exact OS/compiler/flags one looks at). That's around 2% of total codesize. A bit over half the savings was codesize reduction in core code.

Darin, dbaron, jst, dougt, and all others who helped make this patch happen deserve a big thank you.

Posted by bzbarsky at February 20, 2004 1:26 AM
Comments

Wow, those are impressive figures, i would love to see more posts like this, really enjoy reading about the progress You guys make on the core Gecko components.

Excellent work guys!

Posted by: Shadow3333 on February 20, 2004 5:06 AM

It's great to see Gecko extending its performance lead over the competition.

Unfortunately, there are some cases where it still trails IE by a *very* large margin. See http://bugzilla.mozilla.org/show_bug.cgi?id=188294 for one such example (note that although this bug is most prominent on Mac and BeOS, it is also very visible on Windows and other platforms).

Prog.

Posted by: Prognathous on February 20, 2004 10:39 AM

The problem is that the bidi code is just very inefficient in a number of ways. Unfortunately, fixing it requires actually understanding the Unicode bidi algorithm well, which is a pretty high barrier to working on it....

Posted by: Boris on February 20, 2004 11:05 AM

Is that all? I want a 50% size reduction and 500% speedup.

Posted by: alanjstr on February 20, 2004 3:51 PM

Cool!
Stop being so picky alan:P

Posted by: Kah on February 20, 2004 3:54 PM

Is there any reason why the performance of this bidi code should be so vastly different on various platforms? I thought we don't rely on the OS own text handling, but implement our own...

Prog.

Posted by: Prognathous on February 21, 2004 3:50 AM

My first guess would be the text-measurement code (which is platform-specific, as are all the font apis).

Posted by: Boris on February 21, 2004 12:56 PM

This speedup is definitely good! We're still not quite up to IE-level OS-loaded speed, but these 3% gains all come together to make huge gains over time.

If you have the time (you probably don't with everything you do with Mozilla), could you put some padding/margins in the comments code on your blog? The page contents run from column 0 all the way to the scrollbar, so it's somewhat hard to read near the edges.

One last: sorry for my little blunder on the rgba/hsla bug (147017) a couple weeks back. The setup the way I saw it didn't look quite right, but I figured maybe it was just something devs hadn't had time to look at recently. I've been trying to step a little more lightly recently, and so far I haven't completely screwed up again.

Posted by: Jeff Walden on February 22, 2004 9:10 PM

Oops. I kept meaning to clean up the part of the stylesheet for this page and kept putting it off... done now. Margins, normal size fonts, a bit of finagling with the entry separators, etc.

As for the rgba/hsla thing, don't take it to heart too much. I admit the situation is not as clear as it could be... ;)

Posted by: Boris on February 22, 2004 10:09 PM
Post a comment