-
Notifications
You must be signed in to change notification settings - Fork 20
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
Refactoring & Optional data concurrency #35
Comments
Refactoring the code is fine, to an extent. This is very much a style thing, and I don't want to pre-approve anything that I'll regret later on. That said, I agree that 2k lines is too big for a well-factored source file. I'm willing to look at a PR adding Rayon, but that PR should include some benchmarks showing at what data magnitude the feature is justified, and documentation exposing that information to end users. Rayon is sometimes a game-changer, but you can't just naively throw it at problems and expect to see an improvement. FWIW: In the context of let mut items = self
.map
.iter()
.map(|(key, count)| (key.clone(), count.clone()))
.collect::<Vec<_>>(); I would be extremely surprised to discover that Either way, a refactor is a wholly separate concern from adding feature-gated Rayon support, so these should be two distinct PRs. |
I agree with your points.
|
|
Sounds good. With regard to benches, I'd recommend |
I was thinking about incorporating rayon in certain sections of the code behind a feature flag.
For instance
pub fn most_common_tiebreaker<F>
could be changed as follows
Similar feature flag based dependencies would be set in
Cargo.toml
as well.Overall, this would be integrated in a way that preserves default behavior unless a feature flag is set (likely as
rayon
)If you are open to this, I would first begin by initiating a bit of refactoring first.
Most if not all of the code is situated inside
lib.rs
which is now pushing 2k loc.I think the unit tests can be extracted into
/src/lib/tests.rs
as a separate file.This is in contrast to
/tests/integration_tests.rs
which would be for integration tests.Of course, if any specific test is identified to be more suitable for integration tests I would extract them and organise them as such.
What do you feel about each?
The text was updated successfully, but these errors were encountered: