Finder vs Optimal-Select Poor performance

[entrptaher]

I'm importing the default select and finder, then doing a test against various HTML dom. To my surprise, finder was not able to produce valid id and was a lot slower than select.

Optimal-Select:

Finder:

Surely it produced a little selector, but the cost seems too great (4ms vs 19ms).

I tested it against news.hackernews.com, with this selector,

document.querySelector("#hnmain > tbody > tr:nth-child(3) > td > table > tbody > tr:nth-child(2) > td.subtext > a:nth-child(6)")

This is not noticeable if there are less elements,

Observation:

It's not same everytime, but here are some more tests on same page, just with more elements inside document.body.

Elements inside document.body: 740
Select: 1.54ms
Finder: 1.84ms

Elements inside document.body: 3496
Select: 4ms
Finder: 16ms

Elements inside document.body: 6941
Select: 6ms
Finder: 31ms

Elements inside document.body: 68951
Select: 60ms
Finder: 506ms

I will try to prepare a re-producable example/benchmark. But it really seems something is not right here.

The benchmark on this repo confirms this. It says it's slower speed but still fast enough for regular usage.

Can someone confirm this issue somehow and how can we address this?

[antonmedv]

Hi,
What is Optimize-Select? (Is it https://www.npmjs.com/package/optimal-select ?)

finder isn't slow, 19ms is normal behavior and in fact fast. It is designed that way.

For my use case even 1 second of finding is okay. It depends on use cases. If you need it for some fast path. Try to use another tool or write your own.

Comparison with optimal-select

optimal-select fails to generate selectors some times, and some times generates not unique selectors.
finder generates shorter selectors than optimal-select. Also optimal-select now does not have tests and we have :)

For example, on github.com page:

	finder	optimal-select
fails	0	42
shortest	404	38
longest	.story:nth-child(3) .d-lg-flex:nth-child(2) > .width-full:nth-child(1)	[class="circle d-flex flex-column flex-justify-center text-center p-4 mx-auto mt-6 mb-3 m-md-3 bg-orange box-shadow-extra-large"] [class="d-block f0-light text-white lh-condensed-ultra mb-2"]
size	2.9 kB	4.58 kB

But it really seems something is not right here.

No, everything is right as it should be here. It's the way my algorithm works (brute force algorithm).

[entrptaher]

I tried finder on product hunt, it simply hung up when I scrolled down 20-30 times. The more elements on the page the slower it became.

I shall give you a video demonstration soon.

[entrptaher]

This is the result on current page.

Here are two videos showcasing this:

• This github issue page: Notice how clicking on p element makes finder at least 20x slower. Like it's going over the element list too many times even when it's not needed. 3ms vs 120ms on a simple page like this.
• Producthunt: This is not a Optimal Select vs Finder, but only Finder to find unique selector. Notice how everything gets stuck for a moment whenever I click, later it became ultra fast when I removed finder.

The performance difference is huge. Despite generating similar selectors. There are more customization option for optimal selector which I did not use, the output selector would be very similar in that case.

I want to see if we could improve this library somehow :D

[antonmedv]

We can you more euristics to speedup search a little bit. For example prioritize some selector other anothers.