Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Shocking Truth About CSS

blog.twoalex.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: A Shocking Truth About CSS

#51

Post by isleyaardvark »

qjz wrote: post #48
gizmo wrote: post #43

Earlier quoted context omitted.

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…

Your examples aren't valid HTML, so that approach is fine for quirks mode. But what about valid pages that declare a DOCTYPE? Shouldn't those be parsed from left to right, so the first matching ID that is encountered wins (with any other matching IDs considered errors and disregarded)? 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-fo…

But then the browser would have to validate the page, and then render or re-render the document, wouldn't it?

Re: A Shocking Truth About CSS

#52

Post by [deleted] »

kscaldef wrote: post #35
btilly wrote: post #25

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.

[deleted]

Re: A Shocking Truth About CSS

#53

Post by jqueryin »

rimantas wrote: post #49
jbox wrote: post #46

Earlier quoted context omitted.

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

Exactly. I have an obsession with "optimized" markup, that means avoiding unnecessary elements, ids and classes. Let's not forget that all this stuff sits in markup and gets downloaded on each request. Even if that does not add up to much, I still want to have my code "clean". There is one particular site that inspires me: http://camendesign.com/ — take a look, not a single id or class.

He did this, however, at the expense of convoluted selectors, pseudo-elements, and pattern matching. Personally, I don't find his implementation to be very clean. I guess it's better to have the mess in your closet than wide out in the open, though.

Re: A Shocking Truth About CSS

#54

Post by gridspy »

jacoblyles wrote: post #33
btilly wrote: post #25

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.

Presumably any modern processor would use some form of pipelining, which I think would take instructions back up into the billions. (The pentium 4, if I recall correctly, had a 20+ stage pipeline)

Long pipelines cause issues when branches get mis-predicted. The half processed instructions have to be thrown away.

What you want is a CPU with a short pipeline, a fast clock rate and if possible instruction reordering and multiple dispatch.

Large caches and good branch prediction help a lot too.

Re: A Shocking Truth About CSS

#55

Post by bdr »

riffraff wrote: post #24
ableal wrote: post #3

(from the header:) The Two Alexs Alexes? Alex's? Alexi? Alexim? In hackanonical form, Alexen. As in oxen, vaxen, boxen.

IIRC oxen is a vestigial dual (not plural) form, so quite appropriate.

According to http://www.etymonline.com/index.php?term=ox -- "Oxen is the only true survival in Mod.Eng. of the O.E. weak plural."

From what I can tell, it looks like OE nouns could have either "strong" or "weak" declensions, and this is different from the dual form. Someone on another forum claims that "brethren" is another example.

Re: A Shocking Truth About CSS

#56

Post by riffraff »

bdr wrote: post #55
riffraff wrote: post #24

Earlier quoted context omitted.

IIRC oxen is a vestigial dual (not plural) form, so quite appropriate.

According to http://www.etymonline.com/index.php?term=ox -- "Oxen is the only true survival in Mod.Eng. of the O.E. weak plural." From what I can tell, it looks like OE nouns could have either "strong" or "weak" declensions, and this is different from the dual form. Someone on another forum claims that "brethren" is another example.

may well be true, my source is an old State of the Onion talk from Larry Wall, which although a linguist is probably not the most qualified in the world :)

Re: A Shocking Truth About CSS

#57

Post by gizmo »

qjz wrote: post #48
gizmo wrote: post #43

Earlier quoted context omitted.

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…

Your examples aren't valid HTML, so that approach is fine for quirks mode. But what about valid pages that declare a DOCTYPE? Shouldn't those be parsed from left to right, so the first matching ID that is encountered wins (with any other matching IDs considered errors and disregarded)? 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-fo…

You have to write R2L parsing logic anyway, because it's what you want most of the time (e.g. "div span a.quote"). Yes, in the special case where #uniq identifiers are used and you know the page to be valid (X)HTML and you know that you get a substantial speedup by filtering on the #uniq node first L2R parsing is preferable. But how realistic is that, really?

Isn't it just easier to teach web developers to write their DOM selectors in a specific way? The R2L approach is (a) easy to understand (b) has predictable (and stable) performance (c) doesn't malloc (d) is easy to implement. I see this as a simple case of "good enough".

Re: A Shocking Truth About CSS

#58

Post by Tuna-Fish »

btilly wrote: post #25
Tuna-Fish wrote: post #23

Earlier quoted context omitted.

> a computer capable of executing millions of instructions per second Billions, not millions.

Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.

The core i7 can issue 4 instructions, and execute 6 micro-ops per cycle. As long as your code is not a single huge dependency chain, you are mostly reading data out of L1 cache, and you don't use complex instructions like division, you can expect to get at least 2 instructions per clock. I have profiled real code (crypto stuff) that got a tad bit over 3 instructions per cycle. That's 10 billion instructions a second on the processor it ran on.

Most instructions have not taken over 2 cycles on x86 since P4. This is a mesofact, update your worldview. :)

Re: A Shocking Truth About CSS

#59

Post by arsduo »

goodside wrote: post #2

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

It's not every day you can experience all the astonishment of overturning a fundamental assumption without any of the pain of forced changes. I enjoyed that conversation. (I'm Alex K, btw.)

Thanks for all the comments, everyone! Very cool to have that post picked up by Hacker News.

Re: A Shocking Truth About CSS

#60

Post by arsduo »

ableal wrote: post #3

(from the header:) The Two Alexs Alexes? Alex's? Alexi? Alexim? In hackanonical form, Alexen. As in oxen, vaxen, boxen.

Alexen is awesome. I just added it to the header. (Hackanonical is even more awesome, but it sadly doesn't fit there.)

Thanks for the words!

Alex K

PS I appreciate how strong codex/codices example is, but, well, Alices, not so much.

Post reply on HN