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

Replaced "non-efficient" implementation #1681

Closed
wants to merge 3 commits into from

Conversation

arthurmilliken
Copy link

I was a bit confused when I read this example, where the "non-efficient" and "efficient" implementations were identical, except for error-checking, and using a &str for the filename.

When reading the following message at the bottom of the document:

This process is more efficient than creating a `String` in memory
especially working with larger files.

...it seems to me that the original intention was for the "non-efficient" implementation to read the file contents entirely into memory first, then perform parsing on the in-memory String. This PR provides that implementation.

(However, it might be noted that this "non-efficient" implementation actually performs ~7x faster than the "efficient" one, when dealing with a small file!)

…re file contents into a String before parsing lines, as described at the bottom of the document
@rustbot
Copy link
Collaborator

rustbot commented Feb 12, 2023

Failed to set assignee to marioidival: cannot assign: HTTP status client error (403 Forbidden) for url (https://api.github.com/repos/rust-lang/rust-by-example/issues/1681/assignees)

Note: Only org members, users with write permissions, or people who have commented on the PR may be assigned.

@rustbot
Copy link
Collaborator

rustbot commented Feb 12, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @marioidival (or someone else) soon.

especially working with larger files.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consider

This process is more efficient than creating a `String` in memory,
especially when working with larger files.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right. Also consider this comment at the top of the file:

This method is NOT efficient. It's here for beginners
who can't understand the efficient method yet.

Shouldn't the implementation given actually be an "inefficient" in-memory approach, given this comment at the top of the file?

As it currently stands, both the "inefficient" and "efficient' approaches use the exact same implementation, calling io::BufReader::new(file).lines() to parse the file. Why go through all the trouble of warning the user that the first implementation is "NOT efficient", when it uses the exact same approach as the "efficient" solution?

Shouldn't the two approaches actually be different from each other?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, I was merely commenting on the punctuation and the when in this sentence.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm 100% in sync with the change you propose here, although you'll have to duke it out with #1679

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, understood, thanks for the clarification!

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed the proposed update, but looks like #1679 goes through a little more trouble to clean up the prose 😄

Copy link

@theredpea theredpea Mar 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate this pull request #1681, thanks @arthurmilliken , but I guess I prefer #1679 because its beginner friendly method(s) are more accessible to my beginner brain! (and more consistent with the beginner-friendly methods proposed in #1480)
#1679 's beginner friendly methods:

  • avoids &mut
  • avoids closure syntax | line | line.to_owned()
  • uses line breaks to help readability/fluency

Thanks again for everyone's help, it's great to reinforce my learning Rust :)

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.

None yet

5 participants