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

indexOfSlice has horrible performance for arrays and lists #4828

Closed
scabug opened this issue Jul 22, 2011 · 9 comments
Closed

indexOfSlice has horrible performance for arrays and lists #4828

scabug opened this issue Jul 22, 2011 · 9 comments
Assignees

Comments

@scabug
Copy link

@scabug scabug commented Jul 22, 2011

indexOfSlice is implemented using operations that have horrible performance characteristics for mutable data structures, including Array, and for slow-to-index data structures, including List.

One problem (I'm not sure if it's the only problem) is that SeqLike's indexOf method (in the SeqLike companion) is used, which blindly uses drop and slice even if you're not actually slicing anything, then launches into an index-based searcher that shouldn't need the sliced data (and is slow as molasses for List anyway). So, for arrays you make a bunch of extra copies when none are needed, and for lists, you traverse the list a bunch of times when this is not needed. (lastIndexOfSlice is even worse, because it reverses the entire data structure instead of searching backwards.)

The changes needed are:

(1) Move the search logic from SeqLike.KMP into SeqLike.indexOf, so you can use indexing without copying, or at least use views.

(2) Move the SeqLike stuff into IndexedSeqOptimized and implement the routines differently for SeqLike (probably with an iterator on the main collection).

(3) Write a backwards-KMP or at least use views so you don't need to copy huge data structures to see something at the end.

I will write a patch if given a specific go-ahead and/or directions on what is considered acceptable and what is not. I'm actually too busy right now to write a patch, but will make an exception (i.e. get that much less sleep) if I am reasonably confident it will be included and benefit me and others in a reasonable timeframe.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Jul 22, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4828?orig=1
Reporter: @Ichoran
Affected Versions: 2.9.0
Attachments:

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 2, 2011

@paulp said:
Anything which retains interface compatibility and is "better" is a win. It doesn't sound like what you want to do is controversial; if there is a big other side of the coin, let me know, otherwise you should write the patch and it will be included and benefit you and others in a reasonable time frame.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 2, 2011

@paulp said:
I would assign it to you, but jira says I can't do that, so I assigned it to myself, but I'm considering it yours until you say otherwise.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 2, 2011

@paulp said:
I added you to the developer group. Now you are an assignation target. Hide!

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 4, 2011

@Ichoran said:
All right. I assume I'm supposed to fix trunk, and we'll leave 2.[89].x to be slow (or someone else can backport?).

The only downside I'm aware of is more lines of code.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 4, 2011

@Ichoran said:
Argh, ninjas already!

ArrayStack should be IndexedSeqOptimized but is not even IndexedSeq. I guess I'll leave this alone for now given that I doubt a lot of people want really fast indexOfSlice on ArrayStack.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 9, 2011

@Ichoran said:
This is a patch against r25464 that fixes the issue. List is no longer used for indexing, and indexing is used instead of slicing to get sub-sequences. The behavior of indexOfSlice and lastIndexOfSlice is unchanged; I have not tested every corner case for SeqLike.indexOf, but some of those will likely be different (since they didn't seem to make sense anyway--if you look for an empty slice, you can return an element completely out of range of the collection?).

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 9, 2011

@paulp said:
Do you mean like the fact that "(0 to 20).indexOfSlice(Nil, 100)" returns 100? Do you have a different suggestion? It could be -1, but the case would have to be spectacular to change it to failure.

@scabug

This comment has been minimized.

Copy link
Author

@scabug scabug commented Aug 9, 2011

Commit Message Bot (anonymous) said:
(extempore in r25483) Optimizations for Seq's implementations of sequence search algorithms.
Contributed by Rex Kerr. Closes #4828, no review.

@scabug scabug closed this Aug 9, 2011
@scabug scabug added the quickfix label Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.