Issue 2528 - Don't parse CSS selectors that have no comma

Issue 2528 - Don't parse CSS selectors that have no comma

[Sebastian Noack, 2015-05-15 11:33:49]

http://codereview.adblockplus.org/4759827771293696/diff/5629499534213120/incl...
File include.preload.js (left):

http://codereview.adblockplus.org/4759827771293696/diff/5629499534213120/incl...
include.preload.js:157: {
Changes in this block are only due to indentation.

[Sebastian Noack, 2015-05-15 12:51:10]

For reference: http://jsperf.com/convert-for-shadow-dom

[Thomas Greiner, 2015-05-15 13:17:32]

LGTM and thanks for the jsPerf measurement

[Wladimir Palant, 2015-05-15 13:52:37]

jsPerf is great of course but what about the real-world relevance? jsPerf
results seem to indicate that we can currently handle 6 million selectors per
second. Typically, we would have around 20000 selectors - meaning that we would
spend roughly 3ms in the code you optimized. This needs to be measured properly
of course but is this code really worth optimizing?

[Thomas Greiner, 2015-05-15 13:56:18]

On 2015/05/15 13:52:37, Wladimir Palant wrote:
> jsPerf is great of course but what about the real-world relevance? jsPerf
> results seem to indicate that we can currently handle 6 million selectors per
> second. Typically, we would have around 20000 selectors - meaning that we
would
> spend roughly 3ms in the code you optimized. This needs to be measured
properly
> of course but is this code really worth optimizing?

I tested that in the code review for #2467 where I suggested this change. Here's
the quote:

"I saw an up to 50% speed improvement on my computer on recode.net (5
frames) compared to the approach without. Generally, there is a speed
improvement for about 90% of page loads but the absolute numbers for
time saved depend on how many frames the page has and seem to vary
between 2ms to 6ms per frame (e.g. 10-30ms on recode.net) from what I've
observed."

Generally, it's code that is executed on a per-frame, per-filter basis.
Therefore the more filters are applied on a page and the more frames the pages
has, the higher the benefit of having this check in place.

[Sebastian Noack, 2015-05-15 13:57:11]

On 2015/05/15 13:52:37, Wladimir Palant wrote:
> jsPerf is great of course but what about the real-world relevance? jsPerf
> results seem to indicate that we can currently handle 6 million selectors per
> second. Typically, we would have around 20000 selectors - meaning that we
would
> spend roughly 3ms in the code you optimized. This needs to be measured
properly
> of course but is this code really worth optimizing?

Yeah, this is what I initially thought. However, Thomas is convinced that it
notably speeds up load time of pages with multiple frames. See the initial
discussion from http://codereview.adblockplus.org/5663214012465152.

[Wladimir Palant, 2015-05-15 14:21:49]

Even 30ms in the content process (i.e. not blocking any network loads) is
something that the user is extremely unlikely to notice. But well - LGTM.