I just spent a little time profiling a bit (as the benchmark runtime seems quite long compared to the C++ version referenced in the article linked to previously), there seems to be an issue with using swapAt: (probably the same issue discussed here) - I just did a simple measurement of PriorityQueue<Int> insert and could see around 7.5M transient allocations. Doing the simple change of manually doing the swapAt: like this in all places:

storage.swapAt(largestDescendantIdx, index)

changed to

let tmp = storage[index]
storage[index] = storage[largestDescendantIdx]
storage[largestDescendantIdx] = tmp

brought this test down to 165K transient allocations and the runtime was basically halved.

And the original benchmark went from:

to:

Not sure if this is a known issue with the swapAt: method, but it seems a bit rough to force two memory allocations per swapAt: operation for a simple small value type.

Also, looking at the removeMax test, there is also a large amount of transient allocations with this backtrace, can't quite understand why though (haven't looked at any others yet).

@AquaGeek - just spent a little time doing an initial profiling, as I got similar results as you on my own machine - the run times per element seemed long compared to the C++ results in the article references earlier so I wanted to dig a bit on root causes. I found at least one thing which is a bummer - it seems swapAt will hit malloc and it is a known issue. So it seems to use around 30% of total run time goes there.

When calling insert(_:at:) the returned index may be different than the requested index in case selected is false rather than true

Checklist

• [X] I've read the Contribution Guidelines
• [X] My contributions are licensed under the Swift license.
• [ ] I've followed the coding style of the rest of the project. (No changes on code were made, only on the documentation)
• [ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
• [ ] I've added benchmarks covering new functionality (if appropriate).
• [X] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
• [X] I've updated the documentation if necessary.

@swift-ci test

When calling insert(_:at:) the returned index may be different than the requested index in case selected is false rather than true

Checklist

• [X] I've read the Contribution Guidelines
• [X] My contributions are licensed under the Swift license.
• [ ] I've followed the coding style of the rest of the project. (No changes on code were made, only on the documentation)
• [ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
• [ ] I've added benchmarks covering new functionality (if appropriate).
• [X] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
• [X] I've updated the documentation if necessary.

The OrderedSetDiffingTests are testing difference and applying methods on the OrderedSet type. Those methods are defined in OrderedSet+Diffing.swift and have an availability annotation. That annotation was missing from the associated test class.

Checklist

• [X] I've read the Contribution Guidelines
• [X] My contributions are licensed under the Swift license.
• [X] I've followed the coding style of the rest of the project. - [ ] I've added tests covering all new code paths my change adds to the project (if appropriate). - [ ] I've added benchmarks covering new functionality (if appropriate).
• [X] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions. - [ ] I've updated the documentation if necessary.

@AquaGeek Nice! It'd be great to see how the performance compares to CFBinaryHeap for equivalent operations (e.g. CFBinaryHeapAddValue and CFBinaryHeapGetMinimum)!

@kylemacomber Here's a quick pass at adding CFBinaryHeap implementations. I'll get the code added here shortly. Somebody definitely needs to check my work here — take the benchmarks with a hefty grain of salt.

Thanks for taking the time to open the issue!

Yep, noticed the combinations thing (it's been sooooo long since my math degree...) after I had hit the problem, did the loops, and moved on before writing the issue %-)

Here's a first pass at performance tests:

@AquaGeek Nice! It'd be great to see how the performance compares to CFBinaryHeap for equivalent operations (e.g. CFBinaryHeapAddValue and CFBinaryHeapGetMinimum)!

swift run no longer successfully run the example because the master branch renamed into main. This is a tiny fix to simply correct the branch name for example.

I'm seeing a similar discrepancy between debug and release for permutations(ofCount:) on my machine: 20 seconds in debug and 0.2 seconds in release. We should see what we can do to close this gap.

Note: for this specific problem I think combinations(ofCount:) is sufficient and it runs in 0.8 seconds for me in debug and 0.08 in release.

@swift-ci please smoke test macOS

@swift-ci please smoke test macOS

rdar://78841971

Hi!

TL;DR - permutations(ofCount:) is slow in debug builds, taking tens of seconds vs explicit nested for loops taking a fraction of a second. Release builds are fine. Hopefully there's a way to mitigate this problem in debug builds so I can use the algorithm along with being able to use the debugger.

Using version 0.2.1

Checklist

• [-] If possible, I've reproduced the issue using the main branch of this package. I have not, but notice that there aren't any changes since 0.2.1 was cut
• [X] I've searched for existing GitHub issues

Steps to Reproduce

Attached is a project you can run. Look in ContentView.swift for aoc1_2 and use the #if there to choose between the permutations version and one that's nested for loops. Run and click the Permute button to run.

TL;DR:

From AdventOfCode 2020, day 1: https://adventofcode.com/2020/day/1 with a 200 element array. Find the triple of elements in the array that add to 2020, then return their product.

    for perm in stuff.permutations(ofCount: 3) {
        if perm[0] + perm[1] + perm[2] == 2020 {
            let solution = perm[0] * perm[1] * perm[2]
            print("FOUND IT \(solution)")
            break
        }

Expected behavior

The permutations runs in amount of time similar to a simple for-loop equivalent

Actual behavior

In Debug mode, it's two orders of magnitude slower, due of course to Swift's lack of optimizations to enhance debuggability. It'd be nice if it were possible to use this algorithm (maybe others? I haven't investigated any others yet) in a debuggable environment. Right now, waiting 25+ seconds for each edit/run/test/curse cycle is a long time.

In release mode, the times are short enough to where it doesn't impact workflow (outside of not being able to debug things outside of print statements)

Sample project: Permutation.zip

Instruments profile of a Debug build. Permutations-instruments.trace.zip . just a quick glance, a lot of time is spent in memory (nanov2) allocation

Currently, OrderedDictionary._checkInvariants() delegates to _UnstableInternals._checkInvariants() which doesn't exist. This updates the invariant check to delegate to the invariant check on OrderedSet instead.

Checklist

• [x] I've read the Contribution Guidelines
• [x] My contributions are licensed under the Swift license.
• [x] I've followed the coding style of the rest of the project.
• [ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
• [ ] I've added benchmarks covering new functionality (if appropriate).
• [ ] I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
• [ ] I've updated the documentation if necessary.