[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 #3 from Yusuke Suzuki <utatane.tea at gmail.com>  2014-05-06 07:23:19 PST ---
(From update of attachment 230789)
View in context: https://bugs.webkit.org/attachment.cgi?id=230789&action=review

>> Source/WebCore/ChangeLog:17
>> +        pattern:    [B, C, D, E, F]
> 
> Shouldn't the pattern be [F, E, D, C, B, A]?

Since we now considers about <B>'s backtracking. <A> is not included in tagNames pattern vector.
In the implementation detail, this vector is [F, E, D, C, B], but to follow the fragment's order in the selector, we describe it as [B, C, D, E, F] now.

>> Source/WebCore/ChangeLog:20
>> +        candidate2: [E, F]            => matched
> 
> You lost me here, why is [E, F] a matching "prefix"?

In this example, "A" doesn't represent actual tag "A". "A" is an identifier for this fragment. Actually, "A" may be "div".
In this time, we assume that prefix [E, F] matches to the [B, C] in this example to show the subsequent matching example.

>> 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.

Thank you! I also prefer the prefix inc/dec because of C++ iterators, I don't know WebKit also prefer it!
I'll change it.

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