41–50 of 70 posts
Earlier quoted context omitted.
Yeah, OK. So just be ignorant instead.
do you read the source of the linux kernel to understand how to use bash? how about the source of a wifi driver before connecting to a network? your premise is rediculous.
yummy trollspam.
Earlier quoted context omitted.
Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.
Except that pipelining, multiple cores, and hyperthreading then bring it back up. So, let's not get overly pedantic here.
Earlier quoted context omitted.
It’s quicker to walk up a DOM tree than it is to walk down - that’s the root reason why browsers have all implemented it this way.
Yeah, but if we do something like this: #alert > p { background: yellow } Surely the intelligent thing for the CSS engine is to look for the one-and-only #alert, rather than work backwards from all the 's? (I am assuming that nodes with ids have their own fast index.)
Suppose you have a DOM tree like this:
div #alert - p, p, p
- div #alert - p [lots of children]
- p - div #alert [lots of children]
In order to find all Ps with an #alert parent, you first get a set of all paragraph elements. Most likely a list of all paragraphs is kept in memory, so it can be enumerated quickly. Since DOM trees are generally well balanced the number of parents of any one paragraph is going to be roughly O( 2log(|DOMSIZE|) ) and it can be enumerated in C, so this is basically nothing (compared to how grossly inefficient javascript is). Total complexity: O( |P NODES| * 2log( |DOMSIZE| ) ). Memory complexity: 1 linked list of size of result set.
[left to right]
If we were to look at it from left to right, it gets trickier. You have to find all #alert nodes (easy & fast), but then you have to take all children of all #alert nodes. Every sub-tree of the DOM can be a significant fraction of the entire DOM tree, or perhaps the _entire_ dom tree. Not only that, but you CANNOT filter for all "p" children, because then you'd need to have lookup tables for every level in the tree (hugely inefficient). So you're left with one solution, that is to enumerate all children (and a DOM node can have a few thousand child nodes easily). But, wait, one #alert contains another #alert. We're already looking at O( |DOMSIZE| * |DOMSIZE| ), and now we have to consider uniqueness as well. We cannot alloc a hash map to keep track of uniqueness, because that would completely fragement your memory space; you'd end up allocating&deallocating hashmaps for every selector call. So you end up having to traverse the result set linked list for every node you add, to see if it isn't already in there. This, needless to say, is another O(N^2) detour. Total worst case complexity for M selectors:
O( M * |DOMSIZE|^2 + M * |RESULTSET|^2 ).
Difference becomes more profound as complexity increases:
#uniq p p span b
(L2R) find all #uniq nodes, enumerate all "p" children. Make sure all "p" children are unique. Take all children of these "p" nodes, filter for "p" children, make sure result set is unique. Take all children of these "p" nodes, filter for "span", make sure.... and so it goes.
So that's why.
Scroll to the botom, and: 11:44:33 AM Alex K: that makes it sound like it may not be worth huge optimization? 11:44:46 AM Alex M: no, not really
Scroll to the botom, and: 11:44:33 AM Alex K: that makes it sound like it may not be worth huge optimization? 11:44:46 AM Alex M: no, not really
“For most web sites, the possible performance gains from optimizing CSS selectors will be small, and are not worth the costs. ”
http://www.stevesouders.com/blog/2009/03/10/performance-impa...
https://chrome.google.com/extensions/detail/ognampngfcbddbfe...
It's Chrome-only but you can sometimes get cross-browser insights. It's also a lot easier to conduct a cursory investigation using this tool than it is to start changing your selectors.
Earlier quoted context omitted.
Yeah, but if we do something like this: #alert > p { background: yellow } Surely the intelligent thing for the CSS engine is to look for the one-and-only #alert, rather than work backwards from all the 's? (I am assuming that nodes with ids have their own fast index.)
It's a little trickier when you do it left to right. Suppose you have a DOM tree like this: div #alert - p, p, p - div #alert - p [lots of children] - p - div #alert [lots of children] [right to left] In order to find all Ps with an #alert parent, you first get a set of all paragraph elements. Most likely a list of all paragraphs is kept in memory, so it can be enumerated quickly. Since DOM trees are generally well b…
OT, this was one of the problems XHTML was supposed to solve, since it was originally assumed by many that pages that weren't well-formed XML would not be rendered at all, forcing the developers to fix the code. This didn't happen, and developers are still at the mercy of how individual browsers implementat quirks mode.
Scroll to the botom, and: 11:44:33 AM Alex K: that makes it sound like it may not be worth huge optimization? 11:44:46 AM Alex M: no, not really
Steve's final conclusion: “For most web sites, the possible performance gains from optimizing CSS selectors will be small, and are not worth the costs. ” http://www.stevesouders.com/blog/2009/03/10/performance-impa...