- From: Francois Remy <fremycompany_pub@yahoo.fr>
- Date: Thu, 24 Jul 2008 22:38:11 +0200
- To: "Andrew Fedoniouk" <news@terrainformatica.com>
- Cc: "Boris Zbarsky" <bzbarsky@MIT.EDU>, "www-style list" <www-style@w3.org>
From: "Andrew Fedoniouk" <news@terrainformatica.com>
>
> Francois Remy wrote:
>> > /* I don't have better solution if we must generalize in JScript */
>> > setInterval(update, 500);
>> >
>> > (As far as I understand you think that there is a better
>> > solution, right?)
>> >
>> > Your function update() {} has worst case complexity O(n*n).
>> > You can *easily* hit the point when it will take more than 500ms
>> > to execute. So UA will be busy crunching selectors most of the time.
>> >
>> > Cheers.
>> >
>> > --
>> > Andrew Fedoniouk.
>>
>> Yes, there's another solution : you can watch change applied on the
>> elements that can change the value of the rule.
>> But it's not possible to know when an element changes in JScript...
>
> Imagine that I you have some event that is fired when one of its
> attributes, states or its subtree is getting changed.
> (Lets put aside for the second when such an event needs to be fired)
>
> How it will help you?
You don't need to run the whole selector each time there's a DOM
modification, only each one that are applying on elements that are concerned
by the rule.
And yes, I missed a case : when a DIV is added to the document, we must
check the rule for this new div.
>
>> -----------------------------
>> No, it is'nt O(n*n).
>
> It is not O(n*n), it is even worse, see below.
>
>> imagine this case :
>> <div id="base">
>> <div class="el1">
>> <a href="#"><b><span>First</span> link</b></a>
>> <a href="#"><span>Second</span> link</a>
>> </div>
>> <div class="el2">
>> <a href="#"><b><span>First</span> link</b></a>
>> <a href="#"><span>Second</span> link</a>
>> </div>
>> </div>
>> and this rule :
>> div#base div.el1:with-child(a:hover b) span:hover { color: green; }
>> -------------------------------
>> The complexity of #base .el1 a:hover is O(n).
>
> Agreed at this point.
Ok, so it's O(n)
>
>> The rule need to be reevaluated each time :
>> - (1) The elements matched by "div" change (any DIV can get or loose
>> id="base")
>> - (2) The elements matched by "div#base div" change (any DIV of
>> div#base can get or loose class="el1")
>> - (3) The elements matched by "div#base div.el1 span" change (any SPAN
>> can get or loose :hover)
>
> Each of this operations is by itself O(n) operation.
> Complexity of this step is O(3*n).
So, you're saying that O(n) is equals to O(3*n) ?
Because here, it's only the cases when we need to reevaluate a part of the
div#base div.el1 span.
And on the same rule, you agreed with me that it's a O(n) rule... You'ren't
consistent here.
>
> So on *each DOM modification* you will run O(3*n) operation.
> For each element found you need to check for $(#base .el1 a:hover).
Not really. We only need to check if there's a "a:hover b" child in the
matched div.
It's not a O(n), it's smaller. In fact, I think O(...) is not the good way
to say if a rule is complicated or not because it's simply irrevelant.
" span[title='1'] > span[title='2'] > span[title='3'] > ... > span[title=n]
" is really painfull for the UA but it's a O(n).
But "span" is a O(n) too, and he's very simple.
If fact, we don't need to think so.
We must see how much recursion are done to apply the rule.
For "span" it's 1.
For "span[...] > ...." it's n.
For "span:with-child(span)", it's 2.
For [[ before-selector:with-child(child-selector) after-selector ]], it's
I(before-selector) + I(after-selector) + I(child-selector)
So for div#base div.el1:with-child(a:hover b) span:hover, you have a
loop-complexity of 5.
You can see my code, there's only 2 loops for before-selector, 2 loops for
child-selector and then 1 loop for after-selector.
"a b c d e" also have a loop-complexity of 5, and it's not a difficult rule
to evaluate.
"a b:with-child(c d) e" is not really more complex than the first one.
> Therefore total (worst case) is O(m*n*n) where 'm' is a number of simple
> selectors of the complex selector.
>
>> It's a O(n) complexity, you can trust me at this point.
>
> I will.
>
> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
Received on Thursday, 24 July 2008 20:39:45 UTC