[Webkit-unassigned] [Bug 132546] CSS JIT: reduce cost of computing backtracking height

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=132546





--- Comment #2 from Benjamin Poulain <benjamin at webkit.org>  2014-05-06 00:24:12 PST ---
(From update of attachment 230789)
View in context: https://bugs.webkit.org/attachment.cgi?id=230789&action=review

Sorry, I only had a quick look, I had two crazy days.

I see what you are going for here, but I am a little puzzled by the change log. Can you explain from the comment bellow?

One little thing that would be nice in the changelog is explaining that your reasoning also applies for tagNameNotMatchedBacktrackingStartHeightFromDescendant because the subset before the "not matched" must have matched.

> Source/WebCore/ChangeLog:13
> +        For example, consider selector "A>B>C>D>E>F G"'s descendant chain,
> +        "A>B>C>D>E>F".

I am somewhat confused by the example...

> Source/WebCore/ChangeLog:17
> +        pattern:    [B, C, D, E, F]

Shouldn't the pattern be [F, E, D, C, B, A]?

> Source/WebCore/ChangeLog:20
> +        candidate2: [E, F]            => matched

You lost me here, why is [E, F] a matching "prefix"?

> Source/WebCore/cssjit/SelectorCompiler.cpp:719
> +    for (unsigned largestPrefixSize = maxPrefixSize; largestPrefixSize > 0; largestPrefixSize--) {

Traditionally, in Webkit we prefer the prefix increment/decrement instead of suffix operations (because of iterators).

It really does not matter here, this is just for info.

> Source/WebCore/cssjit/SelectorCompiler.cpp:757
> +            RELEASE_ASSERT(tagNames.size() >= previousChildFragmentInDescendantBacktrackingChain->tagNameMatchedBacktrackingStartHeightFromDescendant);

Ensuring there is no overflow here is a great use of RELEASE_ASSERT :)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.