Bug 203544 – [FreeType] Too slow running encoding/legacy-mb-korean/euc-kr WPT tests

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Carlos Alberto Lopez Perez]

The WPT tests encoding/legacy-mb-korean/euc-kr take too much in WebKitGTK. Like 5x more times than with other browsers.

An example of such test is: https://w3c-test.org/encoding/legacy-mb-korean/euc-kr/euckr-decode-ksc5601.html

On the WebKitGTK MiniBrowser it takes around 2 minutes to execute, but on other browsers (firefox, chrome) it executes in less than 15 seconds.

Note that the issue is only reproducible from a cold run. If the page is reloaded, then the second time it loads faster.


Related: https://github.com/web-platform-tests/wpt/issues/19961#issuecomment-547200149

[Carlos Alberto Lopez Perez]

I have run perf over the WebProcess and it seems the biggest issue is by far the call to FcFontMatch inside FontCache::systemFallbackForCharacters()

Another test is just loading this page https://w3c-test.org/encoding/legacy-mb-korean/euc-kr/euckr_chars-ksc5601.html and checking that it draws the characters correctly and the time it takes to load.

[Carlos Alberto Lopez Perez]

Looking at the blame log it looked like r229164 could be related. So I checked to build WebKitGTK on r229163 and r229164
and check the load times of https://w3c-test.org/encoding/legacy-mb-korean/euc-kr/euckr_chars-ksc5601.html
(from a cold start and loading the html from disk to avoid network latencies)


r229163  7 seconds
r229164 13 seconds
r251384 30 seconds


So, r229164 caused the first regression of almost a 100%, and this further regressed more after that.
I still don't know which revision(s) caused the second regression, probably its worth bisecting.

[Carlos Alberto Lopez Perez]

(In reply to Carlos Alberto Lopez Perez from comment #2)
> I still don't know which revision(s) caused the second regression, probably
> its worth bisecting.

The one that caused this second regression (from 13 seconds to 30 seconds) it seems it was r230559

I can get the 13 seconds performance back by running minibrowser (on r251384) with the env var WEBKIT_FORCE_COMPLEX_TEXT=0

[Carlos Garcia Campos]

Created attachment 382440 [details]
Patch

[Carlos Alberto Lopez Perez]

Comment on attachment 382440 [details]
Patch

r=me
Amazing patch! Now the test takes just only 3 seconds. At least a 10x improvement! :)

[Carlos Garcia Campos]

Committed r252044: <https://trac.webkit.org/changeset/252044>