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

Simplified traverse method for vectors by using foldLeft #2091

Closed
wants to merge 1 commit into from

Conversation

amitayh
Copy link
Contributor

@amitayh amitayh commented Dec 10, 2017

By doing this, there's no need for the Eval wrapper and avoiding the
foldRight which could potentially be more efficient

By doing this, there's no need for the `Eval` wrapper and avoiding the
`foldRight` which could potentially be more efficient
@codecov-io
Copy link

codecov-io commented Dec 10, 2017

Codecov Report

Merging #2091 into master will decrease coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2091      +/-   ##
==========================================
- Coverage   94.63%   94.63%   -0.01%     
==========================================
  Files         318      318              
  Lines        5391     5390       -1     
  Branches      209      210       +1     
==========================================
- Hits         5102     5101       -1     
  Misses        289      289
Impacted Files Coverage Δ
core/src/main/scala/cats/instances/vector.scala 72.09% <100%> (-0.64%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3e1a053...47cb3fd. Read the comment docs.

@ceedubs
Copy link
Contributor

ceedubs commented Dec 10, 2017

Thanks for bringing this up, @amitayh.

It could potentially be more efficient, but foldLeft is also always going to do a full traversal of the vector. For example consider the code (1 to 100000).toVector.traverse[Option, Int]{i => println(i); None}. With the current implementation, it will print 1 and then halt. With your change it will print the full range.

I actually thought that we had some tests that were checking that traverse was short-circuiting, but it appears that we don't at least for Vector. While there are definitely trade-offs between the two approaches, I'm inclined to think that the current implementation is probably a better default. I think that we should probably add some tests to ensure the traverse is short-circuiting the structure when possible.

@ceedubs
Copy link
Contributor

ceedubs commented Dec 10, 2017

It looks like we have these tests for List, Stream, and a couple of other types. I'll submit a PR to add them for Vector.

ceedubs added a commit to ceedubs/cats that referenced this pull request Dec 10, 2017
This adds a test case that the `traverse` implementation for `Vector`
short-circuits the traversal when possible. This would have failed the build
in typelevel#2091.

See typelevel#1015 for when similar tests were added for similar structures.
johnynek pushed a commit that referenced this pull request Dec 10, 2017
This adds a test case that the `traverse` implementation for `Vector`
short-circuits the traversal when possible. This would have failed the build
in #2091.

See #1015 for when similar tests were added for similar structures.
@johnynek
Copy link
Contributor

Can we add benchmarks when we are making such trade offs?

@amitayh
Copy link
Contributor Author

amitayh commented Dec 12, 2017

Is there some tool you're using for benchmarking? I can try to run a few tests...

@ceedubs
Copy link
Contributor

ceedubs commented Dec 12, 2017

@amitayh there are some benchmarks in https://github.com/typelevel/cats/tree/master/bench/src/main/scala/cats/bench that would probably be a good starting point.

@amitayh amitayh closed this Dec 17, 2017
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.

4 participants