Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: optimized find for simple cases #515

Closed
Valian opened this issue Dec 26, 2023 · 6 comments
Closed

Proposal: optimized find for simple cases #515

Valian opened this issue Dec 26, 2023 · 6 comments
Labels

Comments

@Valian
Copy link

Valian commented Dec 26, 2023

Feature goal

Currently, Floki.find always creates an HTMLTree, which seems like not always necessary. Consider finding all links, or elements with particular id or class. Basically all cases when we don't need to consider hierarchy of objects and it's enough to look at nodes one-by-one, with a simple traversal.

In a project I'm involved in I noticed slowdowns in that area. A quick traversal is an order of magnitude faster, without memory allocation.

Would you be interested in a PR covering such an optimization? I can try to work on this.

PS Sorry for lack of examples, I'm writing from mobile 😅

@Valian Valian added the Feature label Dec 26, 2023
@philss
Copy link
Owner

philss commented Dec 28, 2023

@Valian I think it worth to explore that path, yes! I can't see a problem upfront. But like you said, this may work only for simple classes and ID selectors.

So please go ahead! Also, take a look at the latest merges - some of them were performance optimizations made by @ypconstante: https://github.com/philss/floki/commits/main/?author=ypconstante

@Valian
Copy link
Author

Valian commented Dec 28, 2023

Thanks, I'll look into this! I know it might work only for simple checks like IDs, tag names and classes, but I have a feeling it might be the most common usage. Eg. finding all links is such an example, which I believe is extremely common.

Will try to find some time on evenings in the next week - two to tackle this.

EDIT: I just checked @ypconstante commits and WOW, there are so many improvements! Possible speedup from my suggested optimization might not be that big, but I'll try to deliver some benchmarks anyway 👍

@philss
Copy link
Owner

philss commented Feb 20, 2024

@ypconstante @Valian do you think this can be closed?

@Valian
Copy link
Author

Valian commented Feb 20, 2024

@philss Sorry recently my family got bigger 👦 and didn't really had time to work on this... But I see @ypconstante did a great job! Are your recent PRs enough to solve this or there is some work still needed?

@ypconstante
Copy link
Contributor

There are still some cases we can enable this optimization without too many changes, like the remaining combinators depending on the selector, and pseudo-classes that don't require the tree.

@philss
Copy link
Owner

philss commented May 21, 2024

@ypconstante I'm closing this now. Once again, thank you for the great work you did to bring these performance gains! ❤️

@philss philss closed this as completed May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants