7 ms·

According to a few runs of this benchmark, a number of these tests are slower in 1.8, particularly selecting by class. That's rather off-putting. I hope it's ju

by mpd 14y ago

According to a few runs of this benchmark, a number of these tests are slower in 1.8, particularly selecting by class. That's rather off-putting. I hope it's just me. Using Chrome 21.0.1180.57 on OSX.

mattparlane 14y ago
I ran it a few times as well and most of the benchmarks seemed to be within statistically insignificant margins, except for three which were much faster -- including $('#id'), which has got to be the most common selector (at least it is in my code). I think it's still worth the upgrade.
- mpd 14y ago
  I use class selection most often, so any slowdown there is a cause of concern for me. The other slowdowns are not as big of a deal, providing it means speedups in more important places.
  - dmethvin 14y ago
    On my system these are the results for the class selector test: 1.7.2 4,123 ops/s 242 microseconds/op 1.8.0 4,061 ops/s 246 microseconds/op Are you seeing some large difference? You'd need to be selecting things by class several hundreds of times a second before it could possibly make a difference. In practical terms, the speedup in custom selectors is probably the most important, since they are so slow.
    - mpd 14y ago
      It's a small difference, but these small differences version after version add up to a lot of nickels. As I mentioned in another comment, increasing performance for ID selection (which is already much, much faster than other types) at the expense of other types makes for sexy benchmarks, but is less than stellar in the real world.
      - kvnn 14y ago
        This is nonsense. Making a huge increase in one type of selector for the sake of an insignificant decrease in another selector is an obvious win.
        bzbarsky 14y ago
        Let's do a simple thought experiment. You have two selectors A and B. A takes 100x more time to evaluate than B (which is about how id and class selectors compare). You evaluate them equally often, say N times each. If the time B takes to evaluate is t, your total execution time is 101t. Now someone comes along and makes B 10x faster while making A 2% slower (which is what the numbers above seem to show for the class selector). Now your execution time is 102.1t, which happens to be larger than 101t. The upshot of all this is that if use frequencies are equal, performance improvements for slow things (even small ones) are worth a lot more than performance improvements for things that are already fast. Now obviously you have to weight by frequency of use, which may differ for different API consumers. There's only one case in which speeding up already-fast stuff at the cost of slow stuff getting even slower is an obvious win regardless of use frequency: benchmarks averaged using geometric means. Which is the most popular averaging method, of course: see Dromaeo, V8 benchmark, PeaceKeeper, etc.
      - bzbarsky 14y ago
        Just out of curiousity, have you considered using querySelector or querySelectorAll directly for your really hot cases? There's a good chance that it'll be faster than the jQuery version in the non-ID cases.
        mpd 14y ago
        Yeah, that's one of the first steps if a selection benchmarks slowly. I just dislike adding complexity in any form. It adds up so quickly in complex software.
DigitalSea 14y ago
Running latest version of Chrome on Windows 7 here and seeing the same things. Nothing is overly much faster and in some instances, like you noticed selecting a class is slower in 1.8 compared to 1.7.2. A little worrying, but I'm sure there's an explanation.
- teamonkey 14y ago
  I'm running Chrome on Win7 and I'm seeing approx 80-90% faster for the id test, but no real difference in any other test.
  - mpd 14y ago
    I'm seeing the same but because ID selection is already 2 orders of magnitude faster than any other type, the net win here is significantly reduced. The rich are just getting richer.
    - kvnn 14y ago
      "the net win here is significantly reduced" Do you mind illustrating how the net performance of jQuery has been reduced with the release of 1.8?

by mpd 14y ago

mattparlane 14y ago

I ran it a few times as well and most of the benchmarks seemed to be within statistically insignificant margins, except for three which were much faster -- including $('#id'), which has got to be the most common selector (at least it is in my code). I think it's still worth the upgrade.

mpd 14y ago
I use class selection most often, so any slowdown there is a cause of concern for me. The other slowdowns are not as big of a deal, providing it means speedups in more important places.
- dmethvin 14y ago
  On my system these are the results for the class selector test: 1.7.2 4,123 ops/s 242 microseconds/op 1.8.0 4,061 ops/s 246 microseconds/op Are you seeing some large difference? You'd need to be selecting things by class several hundreds of times a second before it could possibly make a difference. In practical terms, the speedup in custom selectors is probably the most important, since they are so slow.
  - mpd 14y ago
    It's a small difference, but these small differences version after version add up to a lot of nickels. As I mentioned in another comment, increasing performance for ID selection (which is already much, much faster than other types) at the expense of other types makes for sexy benchmarks, but is less than stellar in the real world.
    - kvnn 14y ago
      This is nonsense. Making a huge increase in one type of selector for the sake of an insignificant decrease in another selector is an obvious win.
      - bzbarsky 14y ago
        Let's do a simple thought experiment. You have two selectors A and B. A takes 100x more time to evaluate than B (which is about how id and class selectors compare). You evaluate them equally often, say N times each. If the time B takes to evaluate is t, your total execution time is 101t. Now someone comes along and makes B 10x faster while making A 2% slower (which is what the numbers above seem to show for the class selector). Now your execution time is 102.1t, which happens to be larger than 101t. The upshot of all this is that if use frequencies are equal, performance improvements for slow things (even small ones) are worth a lot more than performance improvements for things that are already fast. Now obviously you have to weight by frequency of use, which may differ for different API consumers. There's only one case in which speeding up already-fast stuff at the cost of slow stuff getting even slower is an obvious win regardless of use frequency: benchmarks averaged using geometric means. Which is the most popular averaging method, of course: see Dromaeo, V8 benchmark, PeaceKeeper, etc.
    - bzbarsky 14y ago
      Just out of curiousity, have you considered using querySelector or querySelectorAll directly for your really hot cases? There's a good chance that it'll be faster than the jQuery version in the non-ID cases.
      - mpd 14y ago
        Yeah, that's one of the first steps if a selection benchmarks slowly. I just dislike adding complexity in any form. It adds up so quickly in complex software.

DigitalSea 14y ago

Running latest version of Chrome on Windows 7 here and seeing the same things. Nothing is overly much faster and in some instances, like you noticed selecting a class is slower in 1.8 compared to 1.7.2. A little worrying, but I'm sure there's an explanation.

teamonkey 14y ago
I'm running Chrome on Win7 and I'm seeing approx 80-90% faster for the id test, but no real difference in any other test.
- mpd 14y ago
  I'm seeing the same but because ID selection is already 2 orders of magnitude faster than any other type, the net win here is significantly reduced. The rich are just getting richer.
  - kvnn 14y ago
    "the net win here is significantly reduced" Do you mind illustrating how the net performance of jQuery has been reduced with the release of 1.8?