Hacker News Reader

Comment by Jim72 | Hacker News Reader

Please, using more CSS selectors than DOMs isn't going to kill a site. In fact, it isn't even close to being a bottleneck. We are talking milliseconds. If you want speed gains, properly compress your images!

View on HN

I've known about how selectors are processed for some time, I discovered it when I was looking into optimization strategies for JavaScript and figured I should look into how CSS is processed. I made a variety of tweaks, including finally just removing nearly all the CSS, and (somewhat disappointed) did not see any visible changes in the speed at which the browser rendered the page. Not even on IE6/7. Anecdotal evidence only, but to Jim72's point, I wouldn't waste time on it.

Wait, are you saying that a computer capable of executing millions of instructions per second doesn't take very long to do a few comparisons on a dozen or so elements? It takes me a long time to do by hand, so I figured the computer would be really slow too!

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

Except that pipelining, multiple cores, and hyperthreading then bring it back up. So, let's not get overly pedantic here.

Well, it doesn't happen in real life, but an Intel i7 is capable of issuing 4 instructions per clock cycle (sometimes 5, with a little microcode cheating). A 3.2 GHz quad-core could issue 51.2 billion instructions per second.

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)

From CSS to processor design in just 5 comments! Only on HN ;)

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.

Reply on news.ycombinator.com