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

[SR-10673] CaseIterable performance gets worse when used in inlinable function #53073

t-ae opened this issue May 13, 2019 · 1 comment


Copy link

@t-ae t-ae commented May 13, 2019

Previous ID SR-10673
Radar None
Original Reporter @t-ae
Type Bug

XCode 10.2.1

Swift 5.0.1

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, Performance
Assignee None
Priority Medium

md5: 5ce7e64437531ece9384c24ccb8dc264

Issue Description:

public enum RGB: Int, CaseIterable {
    case r, g, b
//    @inlinable
//    public static var allCases: [RGB] {
//        return [.r, .g, .b]
//    }

public func test() -> Int {
    var result = 0
    for _ in 0..<100_000_000 {
        for c in RGB.allCases {
            result += c.rawValue
    return result


I tested above code with time profiler in 3 cases.

  • Case 1: `test` is not inlinable && use automatically implemented `allCases` -> 27ms

  • Case 2: Make `test` inlinable && use automatically implemented `allCases` -> 480ms

  • Case 3: Make `test` inlinable && use manually implemented inlinable `allCases` -> 29ms

In case 2, `RGB.allCases` is always allocating array.
It seems optimization is not working well.

Copy link

@belkadan belkadan commented May 13, 2019

I think this is "correct" behavior, in that if test is inlinable and allCases isn't, you have a function call in your loop that can't be optimized away. However, maybe the default allCases should be inlinable in non-library-evolution code?

cc brentdax (JIRA User), @jtbandes, CodaFi (JIRA User)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants