407462 - Fast-path CJK text (was: several specific sites showing significant Tp regression in 1.9 from 1.8)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Mike Schroepfer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007120705 Minefield/3.0b2pre
Build Identifier: 

See the graphs.mozilla.org link for direct comparisons of 1.8 and 1.9.  In particular

cn.msn.com 295% slower
www.pconline.com.cn 172% slower
tv.mofile.com 181% slower
www.nikkei.com.jp 156% slower
www.asahi.com 326% slower
www.rakuten.co.jp 167% slower 
www.hatena.ne.jp 183% slower
www.cnn.com 120% slower
www.webs-tv.net 182% slower
www.biglobe.ne.jp 184% slower

Each run is 10 cycles and I spot checked a handful of 1.9/1.8 runs to make sure these results were not outliers.   There are many other pages where 1.9 is doing much better than 1.8.  Since these are such outliers they are probably easier to track down and if we can bang them out I bet aggregate Tp for 1.9 will be better than 1.8

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I guess the obvious common factor is that with the exception of cnn.com (which has the least regression here), these are all CJK sites.

Comment 2

[Mike Schroepfer]

I'll note that I spot checked renderings on a few sites in 1.8/1.9 on my mac to make sure 1.8 was actually rendering them correctly - but we should probably do the same on the testing boxes.

Comment 3

[Mike Schroepfer]

Things look worse on the mac - using today's nightly.  

Stored proxy cache of the sites below - which I believe are all licensed in a way to allow redistribution - can be found here:

http://people.mozilla.com/~schrep/mem/proxy_cache.db.free.db

Results below.  Note the top five are 10x, 5x, 3.8x, 3.4x, 1.9x slower on trunk v.s. branch.  Gotta be some good profile fodder there.


page	2009	FF3	FF3/2009
http://joi.ito.com/jp/	1494.5	14939	9.99598527935765
http://zh.wikipedia.org/wiki/	519	2765	5.32755298651252
http://creativecommons.org/	493	1907.5	3.86916835699797
http://wikitravel.org/en/China	771	2659	3.44876783398184
http://de.wikipedia.org/wiki/Hauptseite	236	453	1.91949152542373
http://wikitravel.org/en/Main_Page	177	330.5	1.86723163841808
http://uncyclopedia.org/wiki/Babel:Vi	472.5	874	1.84973544973545
http://spademanns.wikia.com/wiki/Forside	426	773.5	1.81572769953052
http://wikitravel.org/ja/	222.5	391	1.75730337078652
http://wikitravel.org/hi/	226	384.5	1.70132743362832
http://uncyclopedia.org/wiki/Main_Page	629	1053	1.67408585055644
http://ru.wikipedia.org/wiki/	395	637	1.6126582278481
http://en.wikipedia.org/wiki/Main_Page	293	470	1.60409556313993
http://www.armchairgm.com/Special:ImageRating	303.5	464	1.52883031301483
http://ja.wikipedia.org/wiki/	327	493	1.50764525993884
http://ja.uncyclopedia.info/wiki/	514	720	1.40077821011673
http://www.wowwiki.com/Main_Page	453	632.5	1.3962472406181
http://wikitravel.org/ru/	236	319	1.35169491525424
http://en.wikinews.org/wiki/Main_Page	716	944	1.31843575418994
http://pushingdaisies.wikia.com/wiki/Pushing_Daisies	746	953	1.27747989276139
http://www.armchairgm.com/Main_Page	554	682.5	1.23194945848375
http://en.marveldatabase.com/Main_Page	889.5	1089.5	1.22484541877459
http://forums.studentdoctor.net/forumdisplay.php?s=718b9d0e8692d7c3f4cc7c64faffd17b&f=10	761	918.5	1.20696452036794
http://www.armchairgm.com/Anderson_Continues_to_Thrive_for_Cleveland	506.5	597	1.1786771964462
http://forums.studentdoctor.net/showthread.php?t=469342	714	815	1.14145658263305
http://bioshock.wikia.com/wiki/Main_Page	1279	1386	1.08365910867866
http://www.vodcars.com/	576	610	1.05902777777778
http://wikitravel.org/he/	362	359	0.99171270718232
http://joi.ito.com/archives/email/	786.5	756.5	0.961856325492689

Comment 4

[philippe (part-time)]

On CJK sites and sites in Arabic, I've noticed that the slowdown is partially caused when the stylesheet specifies font-families with Roman fonts, or just a generic font and the site is served as UTF-8. Wikipedia Japan and similar wikis are a good example.
The patch in bug 396137 helps quite a bit in my non-scientific testing.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

cn.msn.com's style sheets set font-family to "tahoma,arial,sans-serif". http://joi.ito.com/jp/ is similar. So those are cases where we have to do fallback to language-pref fonts for basically every character.

Comment 6

[Justin Kerk]

(In reply to comment #5)
> cn.msn.com's style sheets set font-family to "tahoma,arial,sans-serif".

Hmm, on CJK Windows locales, Tahoma is linked with the locale's CJK font, see bug 362093. So fixing that bug might help this, at least for Windows users.

Comment 7

[Stuart Parmenter]

Attachment: suck it, uniscribe

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think we could be a bit more aggressive about calling PlaceGDI. Spaces should certainly be allowed. Single characters with only spaces or CJK next to them could also be allowed. OTOH, I guess for cn.msn.com at least, those characters are being drawn in a different font so Place() will still get the optimization. So I guess forget about that for now, but it might matter on some pages.

But how about making allCJK a property of each TextRange, and fuse the allCJK check into the font selection ComputeRanges()? That would be a little simpler and more efficient.

-
+                
             if (rv == E_PENDING) {
                 SelectFont();
                 placeDC = mDC;
                 continue;
             }
-
+                

You're adding extra whitespace there

+        //PRUint32 appUnitsPerDevPixel = aRun->GetAppUnitsPerDevUnit();

You don't need this.

Otherwise great!

Comment 9

[Stuart Parmenter]

Attachment: suck it, uniscribe v2

per our irc conversion not going to move the checking in to TextRange -- this does do a space check though.

Comment 10

[Mike Schroepfer]

As of this morning:


> cn.msn.com 1.06x faster
> www.pconline.com.cn .63 faster
> tv.mofile.com 1.03x faster
> www.nikkei.com.jp 1.23 faster
> www.asahi.com .95x faster
> www.rakuten.co.jp .85x faster 
> www.hatena.ne.jp 1.26x faster
> www.cnn.com .95x faster
> www.webs-tv.net 1.12x faster
> www.biglobe.ne.jp .92x faster

So pretty huge difference

Overall we are doing great in 1.9 - many pages are much faster and the few the are slightly slower have very low loadtimes to begin with.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Do we need a separate bug for the Mac issue from comment 3?

Comment 12

[Stuart Parmenter]

mac stuff has been addressed in many ways since this was filed, but if there are still problems a new bug should be filed, yeah.