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

Jump to bottom

[SR-1577] Ternary operator much slower to compile than if / else #44186

Open
josephlord opened this issue May 21, 2016 · 3 comments
Open

[SR-1577] Ternary operator much slower to compile than if / else #44186

josephlord opened this issue May 21, 2016 · 3 comments
Labels
compiler The Swift compiler in itself improvement performance type checker Area → compiler: Semantic analysis

Comments

@josephlord
Copy link

Previous ID SR-1577
Radar None
Original Reporter @josephlord
Type Improvement
Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Improvement, Performance, TypeChecker
Assignee None
Priority Medium

md5: ff256899ba0f3da0f98368b68df0de47

Issue Description:

A function with this line took about 4 seconds to compile in debug.

let sorted = picks.sort { $0.pick_line == $1.pick_line ? $0.position < $1.position : $0.pick_line < $1.pick_line }

This equivalent version took only 5.4ms:

    let sorted = picks.sort {
        if $0.pick_line == $1.pick_line {
            return $0.position < $1.position
        } else {
            return $0.pick_line < $1.pick_line
        }
    }

picks is an array of instances of an NSManagedObject subclass, position and pick_line are both optional Integer types. (I don't know if this is relevant).

Not sure if this should be labelled "Performance". Is that for issues in the compilation time or the performance of the compiled code.
@belkadan
Copy link
Contributor

The label's context-sensitive. Maybe we should have CompilerPerf and RunTimePerf instead.

@belkadan
Copy link
Contributor

There are several factors that would make the first one slower, the main one being that everything's type-checked together. Specifically:

  • As a multi-statement closure, the body of the second is type-checked separately from the call to sort.

  • The types of the branches of the ternary operator must match, so it all gets type-checked together. We could probably separate out the checking for the condition, but we don't. The second version checks all three pieces separately, and uses the type pre-established by the call to sort.

@swift-ci
Copy link
Collaborator

Comment by Luis Grimaldo (JIRA)

How come this does not have higher priority?
Type-checking in general for Swift seems to be extremely slow.

@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
Assignees
No one assigned
Labels
compiler The Swift compiler in itself improvement performance type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@belkadan @josephlord @swift-ci