Bug 140123 - REGRESSION (r177876): 35% regression in Parser/html5-full-render
Summary: REGRESSION (r177876): 35% regression in Parser/html5-full-render
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 140015
  Show dependency treegraph
 
Reported: 2015-01-06 05:20 PST by Antti Koivisto
Modified: 2015-01-07 01:43 PST (History)
4 users (show)

See Also:


Attachments
patch (4.75 KB, patch)
2015-01-06 05:28 PST, Antti Koivisto
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Antti Koivisto 2015-01-06 05:28:14 PST
Created attachment 244053 [details]
patch
Comment 2 Darin Adler 2015-01-06 10:45:11 PST
Comment on attachment 244053 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244053&action=review

> Source/WebCore/platform/graphics/SimpleFontData.cpp:443
>  RefPtr<SimpleFontData> SimpleFontData::systemFallbackFontDataForCharacter(UChar32 c, const FontDescription& description, bool isForPlatformFont) const

Would be nice to name it "character" instead of "c".

> Source/WebCore/platform/graphics/SimpleFontData.cpp:455
> +        if (c <= 0xFFFF) {

I think we should use U_IS_BMP here.

> Source/WebCore/platform/graphics/SimpleFontData.cpp:480
> +        Vector<std::pair<UChar32, unsigned>> toRemove;

Inline capacity here, maybe?

> Source/WebCore/platform/graphics/SimpleFontData.cpp:484
> +        for (auto& entry : characterMap) {
> +            if (entry.value == this)
> +                toRemove.append(entry.key);
> +        }

Should we have a map in the reverse direction to avoid this iteration?
Comment 3 Antti Koivisto 2015-01-06 11:38:37 PST
https://trac.webkit.org/r177979
Comment 4 Antti Koivisto 2015-01-06 11:42:31 PST
> Should we have a map in the reverse direction to avoid this iteration?

I suspect it is fine as-is. The GlyphPageTree code did a comparable crawl and I don't think we ever had problems with it.
Comment 5 Antti Koivisto 2015-01-06 12:07:35 PST
...and https://trac.webkit.org/r177984
Comment 6 Antti Koivisto 2015-01-07 01:43:39 PST
The bot says performance is back where it was.