I'm trying to improve compile times in my project. I've been using
"-Xfrontend -debug-time-function-bodies" to find to sore spots. Here's
something that takes 1300ms to compile:
I'm not sure what to do from here. My program is unavoidably math heavy.
Every new line of code adds about 60ms of compile time. And that's after I
spend time typing in hints and splitting up the arithmetic.
It doesn't help with this problem, but I use:
-Xfrontend -solver-memory-threshold -Xfronted <SOME-BIG-NUMBER-BUT-LESS-THAN-THE-DEFAULT>
as a way to cause the compiler to give up sooner.
This helps some to identify new troublesome code as it is written, but unfortunately doesn't really help with speeding up code like you posted.
- Daniel
···
On Jan 22, 2016, at 12:25 PM, David Turnbull via swift-users <swift-users@swift.org> wrote:
I'm trying to improve compile times in my project. I've been using "-Xfrontend -debug-time-function-bodies" to find to sore spots. Here's something that takes 1300ms to compile:
public func ortho<T:FloatingPointScalarType>
(left:T, _ right:T, _ bottom:T, _ top:T) -> Matrix4x4<T>
{
let t0:T = T(0)
let t1:T = T(1)
let t2:T = T(2)
let r00:T = t2 / (right - left)
let r11:T = t2 / (top - bottom)
let r30:T = -(right + left) / (right - left)
let r31:T = -(top + bottom) / (top - bottom)
I'm not sure what to do from here. My program is unavoidably math heavy. Every new line of code adds about 60ms of compile time. And that's after I spend time typing in hints and splitting up the arithmetic.
I get the impression that there's no immediate solution. Will Swift 3.0
improve build times?
-david
···
On Fri, Jan 22, 2016 at 2:23 PM, Daniel Dunbar <daniel_dunbar@apple.com> wrote:
It doesn't help with this problem, but I use:
-Xfrontend -solver-memory-threshold -Xfronted
<SOME-BIG-NUMBER-BUT-LESS-THAN-THE-DEFAULT>
as a way to cause the compiler to give up sooner.
This helps some to identify new troublesome code as it is written, but
unfortunately doesn't really help with speeding up code like you posted.
- Daniel
On Jan 22, 2016, at 12:25 PM, David Turnbull via swift-users < > swift-users@swift.org> wrote:
I'm trying to improve compile times in my project. I've been using
"-Xfrontend -debug-time-function-bodies" to find to sore spots. Here's
something that takes 1300ms to compile:
public func ortho<T:FloatingPointScalarType>
(left:T, _ right:T, _ bottom:T, _ top:T) -> Matrix4x4<T>
{
let t0:T = T(0)
let t1:T = T(1)
let t2:T = T(2)
let r00:T = t2 / (right - left)
let r11:T = t2 / (top - bottom)
let r30:T = -(right + left) / (right - left)
let r31:T = -(top + bottom) / (top - bottom)
I'm not sure what to do from here. My program is unavoidably math heavy.
Every new line of code adds about 60ms of compile time. And that's after I
spend time typing in hints and splitting up the arithmetic.
We hope so. Joe Pamer just landed some improvements into the master branch that should improve a lot of common cases, and I believe more improvements are on the way. In the meantime, Bryan Irace recently wrote an article that might help, about using some of the compiler's internal debugging flags to find and improve problem points: http://irace.me/swift-profiling/
-Joe
···
On Jan 23, 2016, at 3:56 PM, David Turnbull via swift-users <swift-users@swift.org> wrote:
I get the impression that there's no immediate solution. Will Swift 3.0 improve build times?
This would be a decent package manager starter bug, I'm guessing it isn't all that much work.
- Daniel
···
On Jan 23, 2016, at 4:03 PM, Joe Groff <jgroff@apple.com> wrote:
On Jan 23, 2016, at 3:56 PM, David Turnbull via swift-users <swift-users@swift.org> wrote:
I get the impression that there's no immediate solution. Will Swift 3.0 improve build times?
We hope so. Joe Pamer just landed some improvements into the master branch that should improve a lot of common cases, and I believe more improvements are on the way. In the meantime, Bryan Irace recently wrote an article that might help, about using some of the compiler's internal debugging flags to find and improve problem points: http://irace.me/swift-profiling/
I've exhausted the method described in that Irace post. He seemed happy
with a 60% improvement. I'm seeing build times 10000% slower than C++. Like
5 minutes vs 3 seconds.
-david
···
On Sat, Jan 23, 2016 at 4:03 PM, Joe Groff <jgroff@apple.com> wrote:
> On Jan 23, 2016, at 3:56 PM, David Turnbull via swift-users < > swift-users@swift.org> wrote:
>
> I get the impression that there's no immediate solution. Will Swift 3.0
improve build times?
We hope so. Joe Pamer just landed some improvements into the master branch
that should improve a lot of common cases, and I believe more improvements
are on the way. In the meantime, Bryan Irace recently wrote an article that
might help, about using some of the compiler's internal debugging flags to
find and improve problem points: http://irace.me/swift-profiling/
I've exhausted the method described in that Irace post. He seemed happy with a 60% improvement. I'm seeing build times 10000% slower than C++. Like 5 minutes vs 3 seconds.
Are you willing/able to share the code for your project? That definitely sounds strange,
-Chris
···
On Jan 23, 2016, at 9:34 PM, David Turnbull via swift-users <swift-users@swift.org> wrote:
-david
On Sat, Jan 23, 2016 at 4:03 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
> On Jan 23, 2016, at 3:56 PM, David Turnbull via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>
> I get the impression that there's no immediate solution. Will Swift 3.0 improve build times?
We hope so. Joe Pamer just landed some improvements into the master branch that should improve a lot of common cases, and I believe more improvements are on the way. In the meantime, Bryan Irace recently wrote an article that might help, about using some of the compiler's internal debugging flags to find and improve problem points: http://irace.me/swift-profiling/
I commented in the bug, but I'll reply here too: this was a debugging tool added for us, and isn't really ready for the average Swift user. In particular:
- It does a pretty lousy job of identifying functions without names
- It doesn't include type-checking of expressions not in function bodies, like initial values for properties
- It only has a (very basic, unsorted) human-readable output form, instead of something properly tabular
- It can only dump to stderr
- It's only function-granular, not statement-granular
- It only includes statement/expression type-checking (though admittedly that's the part of the compiler most likely to have runaway growth)
- It doesn't provide any guidance on how to make things better
I'd rather not commit to providing this feature "publicly" until these problems are at least addressed, if not fixed.
(I'm fine with letting people know about the debug option. I just don't want to consider it an official, supported feature of Swift.)
Jordan
···
On Jan 23, 2016, at 20:21, Daniel Dunbar via swift-users <swift-users@swift.org> wrote:
This would be a decent package manager starter bug, I'm guessing it isn't all that much work.
- Daniel
On Jan 23, 2016, at 4:03 PM, Joe Groff <jgroff@apple.com> wrote:
On Jan 23, 2016, at 3:56 PM, David Turnbull via swift-users <swift-users@swift.org> wrote:
I get the impression that there's no immediate solution. Will Swift 3.0 improve build times?
We hope so. Joe Pamer just landed some improvements into the master branch that should improve a lot of common cases, and I believe more improvements are on the way. In the meantime, Bryan Irace recently wrote an article that might help, about using some of the compiler's internal debugging flags to find and improve problem points: http://irace.me/swift-profiling/
The 28,000 lines of loader code are fine. The 6,000 lines of math libraries
are the problem.
I'm sure it's something to do with prototypes and generics. You can change
in Types.swift:
public protocol FloatingPointScalarType : ScalarType
to:
public protocol FloatingPointScalarType : ScalarType, FloatingPointType
and make the problem a bit worse. This is something I'd actually like to
use, except I don't because a few "where constraints" do what I need
without the build slowdown.
Swift 2.1 or 2.2-dev doesn't make a difference. The C++ compiler I bench
against is also llvm. The compiled binaries are truly fast (with WMO). It's
only the development process that's too slow because of build times.
-David "nyuk nyuk nyuk" Turnbull
···
On Sun, Jan 24, 2016 at 9:55 PM, Chris Lattner <clattner@apple.com> wrote:
Are you willing/able to share the code for your project? That definitely
sounds strange,
Understood. I had presumed designing a proper interface for Swift to provide that information out as a part of the higher level feature (although I guess I didn't make that clear in the bug).
- Daniel
···
On Jan 25, 2016, at 11:41 AM, Jordan Rose <jordan_rose@apple.com> wrote:
I commented in the bug, but I'll reply here too: this was a debugging tool added for us, and isn't really ready for the average Swift user. In particular:
- It does a pretty lousy job of identifying functions without names
- It doesn't include type-checking of expressions not in function bodies, like initial values for properties
- It only has a (very basic, unsorted) human-readable output form, instead of something properly tabular
- It can only dump to stderr
- It's only function-granular, not statement-granular
- It only includes statement/expression type-checking (though admittedly that's the part of the compiler most likely to have runaway growth)
- It doesn't provide any guidance on how to make things better
I'd rather not commit to providing this feature "publicly" until these problems are at least addressed, if not fixed.
(I'm fine with letting people know about the debug option. I just don't want to consider it an official, supported feature of Swift.)
Jordan
On Jan 23, 2016, at 20:21, Daniel Dunbar via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
This would be a decent package manager starter bug, I'm guessing it isn't all that much work.
- Daniel
On Jan 23, 2016, at 4:03 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
On Jan 23, 2016, at 3:56 PM, David Turnbull via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
I get the impression that there's no immediate solution. Will Swift 3.0 improve build times?
We hope so. Joe Pamer just landed some improvements into the master branch that should improve a lot of common cases, and I believe more improvements are on the way. In the meantime, Bryan Irace recently wrote an article that might help, about using some of the compiler's internal debugging flags to find and improve problem points: http://irace.me/swift-profiling/
As JoeG mentions below, I’ve been rolling out a series of major improvements in this area. I’ll take a look at SwiftGL to see what else can be done.
- Joe
···
On Jan 25, 2016, at 12:59 AM, David Turnbull via swift-users <swift-users@swift.org> wrote:
On Sun, Jan 24, 2016 at 9:55 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
Are you willing/able to share the code for your project? That definitely sounds strange,
The 28,000 lines of loader code are fine. The 6,000 lines of math libraries are the problem.
I'm sure it's something to do with prototypes and generics. You can change in Types.swift:
public protocol FloatingPointScalarType : ScalarType
to:
public protocol FloatingPointScalarType : ScalarType, FloatingPointType
and make the problem a bit worse. This is something I'd actually like to use, except I don't because a few "where constraints" do what I need without the build slowdown.
Swift 2.1 or 2.2-dev doesn't make a difference. The C++ compiler I bench against is also llvm. The compiled binaries are truly fast (with WMO). It's only the development process that's too slow because of build times.
The 28,000 lines of loader code are fine. The 6,000 lines of math
libraries are the problem.
I'm sure it's something to do with prototypes and generics. You can change
in Types.swift:
public protocol FloatingPointScalarType : ScalarType
to:
public protocol FloatingPointScalarType : ScalarType, FloatingPointType
and make the problem a bit worse. This is something I'd actually like to
use, except I don't because a few "where constraints" do what I need
without the build slowdown.
Swift 2.1 or 2.2-dev doesn't make a difference. The C++ compiler I bench
against is also llvm. The compiled binaries are truly fast (with WMO). It's
only the development process that's too slow because of build times.
On Mon, Jan 25, 2016 at 10:49 AM, Joe Pamer <jpamer@apple.com <mailto:jpamer@apple.com>> wrote:
Thanks for sharing, David!
As JoeG mentions below, I’ve been rolling out a series of major improvements in this area. I’ll take a look at SwiftGL to see what else can be done.
- Joe
On Jan 25, 2016, at 12:59 AM, David Turnbull via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
On Sun, Jan 24, 2016 at 9:55 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
Are you willing/able to share the code for your project? That definitely sounds strange,
The 28,000 lines of loader code are fine. The 6,000 lines of math libraries are the problem.
I'm sure it's something to do with prototypes and generics. You can change in Types.swift:
public protocol FloatingPointScalarType : ScalarType
to:
public protocol FloatingPointScalarType : ScalarType, FloatingPointType
and make the problem a bit worse. This is something I'd actually like to use, except I don't because a few "where constraints" do what I need without the build slowdown.
Swift 2.1 or 2.2-dev doesn't make a difference. The C++ compiler I bench against is also llvm. The compiled binaries are truly fast (with WMO). It's only the development process that's too slow because of build times.