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

drop, take and slice methods on VectorIterator should not consume linear time #9954

Closed
scabug opened this issue Oct 8, 2016 · 9 comments · Fixed by scala/scala#7654
Closed

Comments

@scabug
Copy link

scabug commented Oct 8, 2016

As an IndexedSeq, VectorIterator does not implement its own drop, take and slice at the moment.
The default implementation in Iterator takes linear time.

This issue also affects views of Vector s.

@scabug
Copy link
Author

scabug commented Oct 8, 2016

Imported From: https://issues.scala-lang.org/browse/SI-9954?orig=1
Reporter: @Atry
Affected Versions: 2.11.8

@atiqsayyed
Copy link

Can I pick this one? I need some guidance on how should i approach it.
I've just started to contribute

@lrytz
Copy link
Member

lrytz commented Aug 17, 2017

This change is most likely not binary compatible (I haven't checked), so it has to target 2.13. In this case, it does not make sense to fix it in the current source code under scala/scala, as the collections library is being reworked at https://github.com/scala/collection-strawman. You could check in the new implementation if the issue is already fixed (or maybe @szeiger knows).

@SethTisue
Copy link
Member

the 2.13 collections are now far enough along that now would be a good time for someone to check if this is resolved there yet or not.

@NthPortal
Copy link

NthPortal commented Mar 2, 2018

It does not seem to be resolved yet - VectorIterator inherits all of the specified methods from Iterator. The implementation of take in Iterator seems to be constant time (I'm not sure why it wouldn't be previously), but the others appear to be linear time.

It might be worth looking to solve this in general for Iterators over IndexedSeqs, rather than just for VectorIterator.

@lrytz lrytz added this to the 2.13.0-M5 milestone Mar 2, 2018
@szeiger
Copy link
Member

szeiger commented May 30, 2018

The more general optimizations could be added to IndexedSeqView.IndexedSeqViewIterator. I'd go a step further and generalized IndexedSeqViewIterator to an IndexedIterator that can be used with any Iterable so you don't need to create the intermediate View. Both should be relatively simple to implement.

This won't be any use for Vector though because it uses its own, even more optimized VectorIterator. You would have to implement another Vector-specifc version of the optimized operations which looks much harder (because you have to know how Vector works internally).

@Ichoran
Copy link

Ichoran commented May 30, 2018

Sequential indexing can often be optimized surprisingly well, but the custom iterator shaves off another 15% of the runtime. Also, it can't always be optimized that well (if the loop is more complex), and then there's a major penalty (~10x, if you have to dig all the way down the 32-wide tree each time).

@szeiger
Copy link
Member

szeiger commented Jan 8, 2019

VectorIterator.drop exists in 2.13 but still no slice or take

@szeiger szeiger self-assigned this Jan 16, 2019
@szeiger
Copy link
Member

szeiger commented Jan 16, 2019

drop exists but turns out to be broken as I discovered while trying to implement take and slice:

scala> Vector.from(0 until 20).iterator.drop(19).knownSize
res7: Int = 1

scala> Vector.from(0 until 20).iterator.drop(20).knownSize
res8: Int = 20

szeiger added a commit to szeiger/scala that referenced this issue Jan 16, 2019
...and fix the `drop` implementation which didn’t ensure that the
remaining size is reported as 0 when all remaining elements are dropped.

Fixes scala/bug#9954
@szeiger szeiger added the has PR label Jan 16, 2019
szeiger added a commit to szeiger/scala that referenced this issue Jan 28, 2019
...and fix the `drop` implementation which didn’t ensure that the
remaining size is reported as 0 when all remaining elements are dropped.

Fixes scala/bug#9954
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants