Base.iterate for TypeSortedCollections

[luke-kiernan]

Yet to do profiling, but it's working. Tests were mostly written by CoPilot.

The tests that are failing are unrelated, would be fixed by rebasing onto main. [I tried doing that, but got conflicts.]

[jd-lara]

it would be great to test the performance of a loop like this

for d in get_components(Device, sys)
foo(d) 
end

vs

for d in TSCO
foo(d)
end

[luke-kiernan]

Just came across this after a few months, so I though I'd post an update. I've come to the conclusion that it's not possible to implement Base.iterate over a TypeSortedCollection in a type-stable way. Quoted from a slack conversation with Jose:

Iteration over a heterogeneous tuple [much less a tuple-of-vectors] isn't type stable! There are some tricks by which it can be made type stable: options being "lisp-y recursion tricks, unrolling, or TypeSortedCollections.jl."

1. Unrolling: when writing Base.iterate, I'm not given the body of the for loop, unlike foreach. Could be done with a macro, but then users can't simply write for item in collection.
2. Lisp-y recursion tricks: works for tuples. For tuples of vectors, though, the return type changes when we move on to the next vector. That seems inherently type unstable. Could be fixed if we knew the lengths at compile time...but then we're basically using a tuple-of-tuples [not a tuple-of-vectors], which will scale poorly for large collections.
3. TypeSortedCollections.jl : I took a look at the original repo, hoping that they implement Base.iterate, but no, only broadcast.

My current suggestion: get_components continues to return a flattened iterator. We add support for TSCs, but only for internal usage in performance critical sections of code. And in order to re-write flatten iterator to TSC, we'll have to refactor for loops as map, mapreduce etc. calls. (In PSI, constructing lines and thermals are two big candidates: large collections and boatloads of different formulations.)