Nearly Impossible to Build a framework using generics

[strike (V T)]

Using Swift 4 the project compiles in 20 min. Using Swift 5, the build process takes 90 min. That is catastrophic.

[Jon_Shier]

There's little anyone can do without more detail. How are you building, what version of the tools are you using, a link to your project, what hardware you're using, etc.

[Jens]

I'll take a wild guess and say that this has probably something to do with operators on generic types, which has become a lot slower to compile in Swift 5, related threads:

Has type checking operators on generic types always been this slow?

The following is too complex for Xcode 10.2.1: let u = SIMD2<Float>(0, 1) let v = SIMD2<Float>(1, 2) let r = [ // ERROR: The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions 2*u + 3*v, 4*u + 5*v ] I've described the same problem in another thread and reported it as SR-10461, but this thread is an attempt to present it more clearly to try and gain some attention and priority. Our projects use a lot of SIMD…

No longer able to type check expressions with Xcode 10.2 (caused by new SIMD API?)

I know for certain that the three lines with i, j and k in test.swift did type check (quickly) prior to upgrading to Xcode 10.2 and macOS 10.14.4. But the compiler is now unable to type check them in reasonable time (i takes forever). test.swift: import simd func test(_ p0: float2, _ p1: float2, _ p2: float2, _ p3: float2) { let i = 3*(-p0 + 3*p1) - (3*p2 + p3) let j = 6*(p0 - 2*p1 + p2) let k = 3*(p1 - p0) print(i, j, k) } test(float2(0.1, 1.2), float2(2.3, 3.4), float2(4.5, …

[strike (V T)]

I will provide some details tomorrow. For now: The reason for long build times is the type checker. I have to make extensive use of generics (classes, structs, functions etc.). Take a look here Unable to type check expression, Xcode 10.2 regression...

My project will be a Statistical/Mathematical Framework.

Xcode 10.2.1, Swift 5
Same project using ObjC (without generics): build time 5 min.

That problem persists over years now.
I like Swift. Really. But 90 min compile time is money that is thrown out of the the window.
A cure can only be achieved by the Swift team.
Thanks anyway!

[strike (V T)]

Yes. That‘s the problem. And it makes me helpless.

[Jens]

Yes, this general type checker issue, and especially the recent regression, is very frustrating.

It's also pretty noticeable, especially with the new SIMD types, which are unusable in expressions involving more than three operators, so I guess we cannot be the only ones who are running into it.

Does anyone know if it's being worked on and if it's considered a prioritized issue?

---

But for quicker a "solution": Have you tried adding the compile flags that makes the compiler report compile times per function?

(EDIT: I see that there are flags for reporting time per expression now too, cool, have to try that.)

I've found that I can drastically (although painstakingly) lower my compile times by inspecting those reports, looking into the worst functions, guessing at which are the problematic expressions that needs breaking up into ones involving fewer operators. Just keep doing this, and compile times will go down a bit for each expression you break up into simpler ones.

I would not be surprised if your project could go from 90 minutes to 1 minute. The price is the time it takes to experiment your way towards code that is easier on the type checker, although more verbose/ugly for humans of course.

Doing this a lot teaches you to write expressions in a (unnatural) way that doesn't make the type checker spend crazy amounts of time on them.

(This also makes me wonder: Why can't some piece of the compiler analyze and break up those expressions into simpler ones automatically?)

[Ponyboy47 (Jacob Williams)]

@Jens

I've found that I can drastically (although painstakingly) lower my compile times by inspecting those reports, looking into the worst functions, guessing at which are the problematic expressions that needs breaking up into ones involving fewer operators. Just keep doing this, and compile times will go down a bit for each expression you break up into simpler ones.

I would not be surprised if your project could go from 90 minutes to 1 minute. The price is the time it takes to experiment your way towards code that is easier on the type checker, although more verbose/ugly for humans of course.

If youre on macOS there is an open source program called the Xcode Build Time Analyzer which can give you a break down of how long each file and even each expression (really just each line) takes to compile. It should sort from slowest lines to fastest.

It makes it a million times easier to figure out exactly which expressions need to be broken up to help the type checker. I personally have take 60 second builds down to 3 seconds. I’m sure your mileage would vary but I guarantee it can help identify the worst expressions much faster and less pain-stakingly.

[strike (V T)]

Thank you for pointing that out. I used the Build Time Analyzer. Also the hints at Github: Optimizing-Swift-Build-Times . It only tells me what I already know.

In my opinion there are two possibilities:

1. either the compiler team doesn't have a solution or
2. the compiler team ignores these problems.

I realize that building the Swift infrastructure is a highly complex task. But at least a statement from the team would be nice.

[tkrajacic (Thomas Krajacic)]

@strike

In my opinion there are two possibilities:

1. either the compiler team doesn't have a solution or
2. the compiler team ignores these problems.

Well, you forgot the most likely which is:

3. The compiler team knows about this, has ideas of how to solve this but didn't have the time to dig into this particular problem.

I think there are many places in Swift where this is the problem right now because there is still so much foundation to lay. I am confident that the right people are working on it but I understand the frustration all too well and can sympathize.

[strike (V T)]

@tkrajacic

3. The compiler team knows about this, has ideas of how to solve this but didn't have the time to dig into this particular problem.

I've indeed forgotten that option Maybe because I am very frustrated. But of course you're right.

[Avi]

It's frustrating, but besides for their usual work on Swift, they've probably been busy for the last month or two preparing for WWDC.

[strike (V T)]

@Avi

... been busy for the last month or two preparing for WWDC.

Of course I understand what you mean. But I have deadlines too.
I also know that critical products should not be built on the latest features of a programming language. My hope was that the use of generic types would be easier in version 5. At least in terms of development time.

I don't want to throw trash either. After all, I'm sitting in the glass house.
The Swift team is doing an excellent job and I am really glad that Swift exists.