chore(Python): Improve slicing performance

[lucasmcdonald3]

What was changed?

Add a new class Slice. This is a lazy slice for Seqs. The elements of a Seq are immutable, so slices of a Seq can refer to the original Seq's elements, and lazily calculate access based on the slice indices. Before, a slice of a Seq would copy all elements by value from the original to the new Seq.

• Slicing a Seq now takes constant time.
• Slicing a Slice takes constant time.
• Getting a single element from a Slice takes constant time.
• Getting the length of a Slice takes constant time.
• Enumerating the elements in a Slice takes linear time.

How has this been tested?

No new functional testing. I hope that existing tests would catch any issues, but let me know if there are any doubts.

I ran a slicing performance test locally.

module Main {
  method Main(args: seq<string>) {
    var longList := seq(TestNum, i => i);
    var currentSeq := longList;
    while |currentSeq| > 0
    {
        var firstElem := currentSeq[0];
        currentSeq := currentSeq[1..];
    }
  }
}

Results from my local:

• TestNum = 10000, Python before change: 9s

• TestNum = 10000, Python after change: <1s

• TestNum = 10000, .NET: ~1s

• TestNum = 1000000, Python before change: at least 10 minutes

• TestNum = 1000000, Python after change: ~1s

I don't plan committing the performance test file, since there's no functional testing there, but let me know if I should.

(I have separate testing in Crypto Tools' Python DBESDK (JSON encryption library) that brings a particular test execution from ~15 minutes to ~30 seconds.)

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.

[lucasmcdonald3]

(I think I'm missing permissions to add #2313 as an issue linked on the PR)

[robin-aws]

Thanks for the contribution!

(I think I'm missing permissions to add #2313 as an issue linked on the PR)

AFAIK you can just say phrases like "Resolves #2313" to make that link happen.

But in this case we shouldn't anyway, since that issue is tracking a more general cross-backend improvement, and this change is just improving things for Python.

[lucasmcdonald3]

Cool, thanks!

I made these changes as part debugging performance issues in Crypto Tools products. Now, I'm running into more performance "hiccups", and might need to make more changes.
Would y'all prefer I add any other changes to this PR, or a new PR?

[robin-aws]

I'd say if the additional changes are small and somewhat related, feel free to add them here. Otherwise getting this merged and working on a new PR is probably better.

[lucasmcdonald3]

I added my changes here because my new changes conflicted with the previous changes.
I'm probably done making significant changes.

[fabiomadge]

Thanks, this is great! Do you have data on the impact of _SeqSlice as well?

[lucasmcdonald3]

Thanks Fabio, updated the code.

I also updated the performance test code and results for the latest implementation.