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.
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.
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.
(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
Created attachment 382440 [details]
Comment on attachment 382440 [details]
Amazing patch! Now the test takes just only 3 seconds. At least a 10x improvement! :)
Committed r252044: <https://trac.webkit.org/changeset/252044>