Skip to content

feat(cable) keep data input order #231

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

Closed
wants to merge 1 commit into from

Conversation

xosxos
Copy link
Contributor

@xosxos xosxos commented Jan 6, 2025

Hey, I had issues with the git log order getting shuffled in tv git-log.

If you want to add another dependency, IndexSet from indexmap, would do the same thing as the HashSet AND preserve order with roughly the same performance rustc PR45282. Also, indexmap is already included in the dependency tree, so this shouldn't really affect compile times either. Cheers

@xosxos
Copy link
Contributor Author

xosxos commented Jan 6, 2025

I think this also at least mostly closes #194

@alexpasmantier
Copy link
Owner

Very nice, that's helpful, thanks 🙏🏻

A couple of tests and linting errors to fix (rebasing on main should do it for the linting issues) and let's merge this.

@xosxos
Copy link
Contributor Author

xosxos commented Jan 6, 2025

Sounds good, and oh yes sorry, I didn't run the tests 😅

@xosxos
Copy link
Contributor Author

xosxos commented Jan 6, 2025

Also, I assume that this use of HashSet is for deduplification, which is a bit problematic as It's potentially a noticeable performance hit to re-allocate there, and at the same time it's unnecessary for many applications such as logs etc. I guess the first thing would be to change the hash algorithm to a faster one and then down the line if it bottlenecks do something a bit more sophisticated.

@alexpasmantier
Copy link
Owner

You're absolutely right.

https://crates.io/crates/rustc-hash should be more than enough here and we might see a noticeable performance improvement.

I do agree deduplicating here does not suit all purposes, but I felt it was nice to have in most cases. If it becomes more of a problematic issue, doing something more sophisticated down the line like you mentioned might be the way to go indeed.

@alexpasmantier
Copy link
Owner

Fyi #237

Thanks for the suggestion 🙏🏻

@alexpasmantier
Copy link
Owner

Ended up dropping the deduplication process altogether in #248 since it solves an issue and is always good for performance.

Closing this, thanks 🙏🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants