5 ms·

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 w

by Jim72 17y ago

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!

jrockway 17y ago
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!
- Tuna-Fish 17y ago
  > a computer capable of executing millions of instructions per second Billions, not millions.
  - btilly 17y ago
    Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.
    - jacoblyles 17y ago
      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)
      - gridspy 17y ago
        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.
      - bruceboughton 17y ago
        From CSS to processor design in just 5 comments! Only on HN ;)
    - kscaldef 17y ago
      Except that pipelining, multiple cores, and hyperthreading then bring it back up. So, let's not get overly pedantic here.
      - deleted 17y ago
        [deleted]
      - deleted 17y ago
        [deleted]
    - sp332 17y ago
      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.
    - Tuna-Fish 17y ago
      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. :)
flatline 17y ago
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.

by Jim72 17y ago

jrockway 17y ago

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!

Tuna-Fish 17y ago
> a computer capable of executing millions of instructions per second Billions, not millions.
- btilly 17y ago
  Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.
  - jacoblyles 17y ago
    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)
    - gridspy 17y ago
      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.
    - bruceboughton 17y ago
      From CSS to processor design in just 5 comments! Only on HN ;)
  - kscaldef 17y ago
    Except that pipelining, multiple cores, and hyperthreading then bring it back up. So, let's not get overly pedantic here.
    - deleted 17y ago
      [deleted]
    - deleted 17y ago
      [deleted]
  - sp332 17y ago
    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.
  - Tuna-Fish 17y ago
    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. :)

flatline 17y ago

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.