3 ms·

> I'm not a front end dev But I am. You are correct in that there many other opportunities to further increase performance. If performance were that important

> I'm not a front end dev But I am. You are correct in that there many other opportunities to further increase performance. If performance were that important you would also shift your attention to equally improve code execution elsewhere in your application stack. > and I've never seen parsing CSS selectors as a bottleneck. It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers. EDIT To everybody asking for numbers I recommend conducting comparative benchmarks using a perf tool. Here is a good one: http://jsbench.github.io/ http://jsbench.github.io/ I posted a performance example to HN before and people twisted themselves into knots to ignore numbers they could easily validate and reproduce themselves.

bscphil 6y ago
It's funny, you say > It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers. But your only argument here is not numbers, but appeal to authority: > > I'm not a front end dev > But I am. I don't have any particular reason to doubt you, but if objective numbers should rule the day here, maybe you could link to an article comparing the performance of a simple application using CSS selectors and then switching to using the DOM API?
pas 6y ago
Could you provide said numbers? Maybe you have seen a lot of pathological cases, but that might not be representative.
- filleduchaos 6y ago
  I'm not the poster in question, but I thought it was pretty well known that querySelector[All] with a class string is shockingly slow - I'm actually a bit confused that everyone here is acting like they said something out of the ordinary. If that's really not common knowledge, it's probably no surprise that people are unintentionally writing websites that run like absolute crap on mobile devices. Here's a JSPerf (not mine) that you can run and see yourself just how bad the performance is: https://jsperf.com/getelementbyid-vs-queryselector/284 https://jsperf.com/getelementbyid-vs-queryselector/284. getElementsByClassName runs nearly five million operations per second on my laptop (8th-gen i7, 16GB of RAM, latest Chrome); querySelector[All] with a class name runs less than ten thousand. And the sample HTML is tiny indeed compared to a typical web site or app.
  - chubot 6y ago
    I think what you're referring to is that querySelector is O(n), while the older getElement APIs are O(1). https://stackoverflow.com/questions/14377590/queryselector-and-queryselectorall-vs-getelementsbyclassname-and-getelementbyid/54819633#54819633 https://stackoverflow.com/questions/14377590/queryselector-a... That makes sense, but it has nothing to do with "string parsing", as the OP said. Parsing the query is fast. Executing the query is slow, because it's a more general API. (And this is why the citation is important: because it shows the real issue, not the one described! Thanks for the clarification.)
    - austincheney 6y ago
      See this: https://news.ycombinator.com/item?id=24058409 https://news.ycombinator.com/item?id=24058409
UberMouse 6y ago
Then provide some numbers?
- filleduchaos 6y ago
  Do these work for you? https://jsperf.com/getelementbyid-vs-queryselector/284 https://jsperf.com/getelementbyid-vs-queryselector/284
  - austincheney 6y ago
    I love how big the numbers are in recent versions of Firefox. On my crappy work computer that can barely run Notepad++ I am pulling 1.8 billion ops for getElementById and getElementsByClassName. The performance gaps: * getElementById vs equivalent querySelector is about 1000x. * getElementsByClassName vs querySelectorAll is about 250,000x. * On Chrome getElementsByClassName vs querySelectorAll is only about 426x. This is a micro-benchmark. In the real world that disparity would magnify almost exponentially with the number of nodes in a given page and the frequency and depth of access requests to the DOM.
    - UberMouse 6y ago
      I decided to check back in this and this seems like it was entirely a wording problem in your first post. Your post implied that _parsing the query selector string_ was slowing down Javascript websites, which obviously made everyone do a hottake and jump in to say that can't be the case. What you seem to _actually_ be saying is that using query selectors instead of finding elements directly by class/id is slow which yes, that's certainly the case.
      - austincheney 6y ago
        Query selectors are slow, yes, but its because they have to parse a string. Other DOM methods don't have a string parsing step. You cannot optimize access to the DOM if there is a string parsing step that must occur first. That barrier to efficiency is greatly magnified by the complexity of the query string, the size of the dynamically rendered page, and the number of query strings. If not for that string parsing step why would query selectors be any different from any other DOM access instruction computationally?
cuddlecake 6y ago
But still, please follow up on [citation needed] please
esperent 6y ago
> > I'm not a front end dev > But I am. So am I, and I disagree with you. Here's an actual benchmark that you can run[1] (why did you not share an actual benchmark?). I get, on my old and slow Android, 500k ops/sec for querySelector. At 60fps, that allows you to do ~8000 selections per frame, assuming you're not doing anything else. In reality, any app I've ever encountered probably has a few hundred querySelector calls, in total, and if the app is well written, the majority of these are cached meaning they only get called once, not once per frame. [1] https://www.measurethat.net/Benchmarks/Show/2488/0/getelementbyid-vs-queryselector#latest_results_block https://www.measurethat.net/Benchmarks/Show/2488/0/getelemen...
- austincheney 6y ago
  500k ops is ridiculously slow for accessing the DOM on any modern hardware. It sounds fast when aren’t comparing it to anything. Compare that to a similar approach that makes use of the standard DOM methods and no selectors. The only thing querySelectors do faster is allow accessing elements by attribute. The reason I refuse to post numbers myself is because: 1. I provided a tool where people can run any manner of discovery for their own numbers and see performance differences in various approaches. 2. People, when presented with a valid comparison will irrationally ignore results that challenge their opinion. EDIT: I looked closer at the measureit experiments and it seems there is some sort of bias. If you run the same experiment using an element already present in the page the results are the same for querySelector but 50% greater for the getElementById approach. Other perf tools I have tried did not display this kind of bias and they also reported substantially higher numbers for all user agents, most especially for desktop Firefox.
  - daerogami 6y ago
    In response to 1, you're asking people to do their own research when you have stated the claim. The burden is on you. As for 2, if it's such a problem, just don't make the argument. It genuinely comes off as wanting people to agree with you rather than any real interest towards engaging in actual discussion.
    - 6y ago

bscphil 6y ago

It's funny, you say > It doesn’t matter what our opinions are or what we have/haven’t seen. The only thing that matters are what the performance measurements say in numbers. But your only argument here is not numbers, but appeal to authority: > > I'm not a front end dev > But I am. I don't have any particular reason to doubt you, but if objective numbers should rule the day here, maybe you could link to an article comparing the performance of a simple application using CSS selectors and then switching to using the DOM API?

pas 6y ago

Could you provide said numbers? Maybe you have seen a lot of pathological cases, but that might not be representative.

filleduchaos 6y ago
I'm not the poster in question, but I thought it was pretty well known that querySelector[All] with a class string is shockingly slow - I'm actually a bit confused that everyone here is acting like they said something out of the ordinary. If that's really not common knowledge, it's probably no surprise that people are unintentionally writing websites that run like absolute crap on mobile devices. Here's a JSPerf (not mine) that you can run and see yourself just how bad the performance is: https://jsperf.com/getelementbyid-vs-queryselector/284 https://jsperf.com/getelementbyid-vs-queryselector/284. getElementsByClassName runs nearly five million operations per second on my laptop (8th-gen i7, 16GB of RAM, latest Chrome); querySelector[All] with a class name runs less than ten thousand. And the sample HTML is tiny indeed compared to a typical web site or app.
- chubot 6y ago
  I think what you're referring to is that querySelector is O(n), while the older getElement APIs are O(1). https://stackoverflow.com/questions/14377590/queryselector-and-queryselectorall-vs-getelementsbyclassname-and-getelementbyid/54819633#54819633 https://stackoverflow.com/questions/14377590/queryselector-a... That makes sense, but it has nothing to do with "string parsing", as the OP said. Parsing the query is fast. Executing the query is slow, because it's a more general API. (And this is why the citation is important: because it shows the real issue, not the one described! Thanks for the clarification.)
  - austincheney 6y ago
    See this: https://news.ycombinator.com/item?id=24058409 https://news.ycombinator.com/item?id=24058409

UberMouse 6y ago

Then provide some numbers?

filleduchaos 6y ago
Do these work for you? https://jsperf.com/getelementbyid-vs-queryselector/284 https://jsperf.com/getelementbyid-vs-queryselector/284
- austincheney 6y ago
  I love how big the numbers are in recent versions of Firefox. On my crappy work computer that can barely run Notepad++ I am pulling 1.8 billion ops for getElementById and getElementsByClassName. The performance gaps: * getElementById vs equivalent querySelector is about 1000x. * getElementsByClassName vs querySelectorAll is about 250,000x. * On Chrome getElementsByClassName vs querySelectorAll is only about 426x. This is a micro-benchmark. In the real world that disparity would magnify almost exponentially with the number of nodes in a given page and the frequency and depth of access requests to the DOM.
  - UberMouse 6y ago
    I decided to check back in this and this seems like it was entirely a wording problem in your first post. Your post implied that _parsing the query selector string_ was slowing down Javascript websites, which obviously made everyone do a hottake and jump in to say that can't be the case. What you seem to _actually_ be saying is that using query selectors instead of finding elements directly by class/id is slow which yes, that's certainly the case.
    - austincheney 6y ago
      Query selectors are slow, yes, but its because they have to parse a string. Other DOM methods don't have a string parsing step. You cannot optimize access to the DOM if there is a string parsing step that must occur first. That barrier to efficiency is greatly magnified by the complexity of the query string, the size of the dynamically rendered page, and the number of query strings. If not for that string parsing step why would query selectors be any different from any other DOM access instruction computationally?

cuddlecake 6y ago

But still, please follow up on [citation needed] please

esperent 6y ago

> > I'm not a front end dev > But I am. So am I, and I disagree with you. Here's an actual benchmark that you can run[1] (why did you not share an actual benchmark?). I get, on my old and slow Android, 500k ops/sec for querySelector. At 60fps, that allows you to do ~8000 selections per frame, assuming you're not doing anything else. In reality, any app I've ever encountered probably has a few hundred querySelector calls, in total, and if the app is well written, the majority of these are cached meaning they only get called once, not once per frame. [1] https://www.measurethat.net/Benchmarks/Show/2488/0/getelementbyid-vs-queryselector#latest_results_block https://www.measurethat.net/Benchmarks/Show/2488/0/getelemen...

austincheney 6y ago
500k ops is ridiculously slow for accessing the DOM on any modern hardware. It sounds fast when aren’t comparing it to anything. Compare that to a similar approach that makes use of the standard DOM methods and no selectors. The only thing querySelectors do faster is allow accessing elements by attribute. The reason I refuse to post numbers myself is because: 1. I provided a tool where people can run any manner of discovery for their own numbers and see performance differences in various approaches. 2. People, when presented with a valid comparison will irrationally ignore results that challenge their opinion. EDIT: I looked closer at the measureit experiments and it seems there is some sort of bias. If you run the same experiment using an element already present in the page the results are the same for querySelector but 50% greater for the getElementById approach. Other perf tools I have tried did not display this kind of bias and they also reported substantially higher numbers for all user agents, most especially for desktop Firefox.
- daerogami 6y ago
  In response to 1, you're asking people to do their own research when you have stated the claim. The burden is on you. As for 2, if it's such a problem, just don't make the argument. It genuinely comes off as wanting people to agree with you rather than any real interest towards engaging in actual discussion.
  - 6y ago