> On Oct 5, 2016, at 3:37 PM, Ben Asher <[email protected]> wrote:
>
> I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems maybe
> 15s faster (to build our main huge target): 7m28s compared to 7m43s. It's
> some improvement, but I'm not exactly sure what kind of improvement was
> expected.
The kind of benefit you might expect really depends on the specific code you’ve
written. The changes I have in mind attempt to speed up the expression type
checker (the thing that does the work of inferring types for a given
expression, and the case where there is an explicit type the expression needs
to type-check to, ensuring that it does). These expressions include things like
array literals and dictionary literals, where we sometimes take a long time to
type check.
> Is there any profiling/tracing you all would recommend to help find problem
> areas?
If you’re looking for problem areas in your particular build, I have a couple
suggestions:
1. Take a look at the output of -debug-time-function-bodies to see if the same
function is getting type checked multiple times, and determine what the
cumulative time for those functions is.
For example below is the output I see for a simple test case. Note that the
getter/setter that are generated from a property on line 2 of two.swift are
type checked twice. Although in this case we type check the individual
functions very quickly, if you have enough of this kind of redundant type
checking happening, it can add up. This *particular* case is a known bug that
we hope to address - the synthesized getters/setters for properties are type
checked in each file they are referenced in.
There may be other cases like this that we’re not already aware of, so it’s
always good to open a bug if you find something like this.
swiftc -c main.swift two.swift -module-name test -Xfrontend
-debug-time-function-bodies
0.2ms main.swift:2:7 get {}
0.2ms main.swift:2:7 set {}
0.0ms main.swift:1:7 @objc deinit
0.3ms main.swift:1:13 override init()
0.2ms two.swift:2:14 get {}
0.2ms two.swift:2:14 set {}
0.2ms two.swift:2:14 get {}
0.2ms two.swift:2:14 set {}
0.0ms two.swift:1:14 @objc deinit
0.0ms two.swift:1:14 init()
2. Add a timer for expression type checking and see if that helps narrow down
whether there is time being spent type checking expressions that isn’t
accounted for in -debug-time-function-bodies. There are a few places that might
make sense for this, but I suspect ConstraintSystem::solve() might be the best.
This is ultimately called from a variety of places, and would provide the most
insight into where time is being spent in the expression type checking. It’s
possible something higher up the stack, like TypeChecker::solveForExpression or
TypeChecker::typeCheckExpression() might make more sense as well. You can model
this on how -debug-time-function-bodies is currently implemented, e.g. look at
swift::performTypeChecking for some help on getting started. I’ll probably try
to add this timer myself in the next few weeks if you don’t manage to beat me
to it.
Mark
> I don't mind building from Swift master, using someone's preferred profiling
> tools, etc. I'm not really sure where to start.
>
> Ben
>
> On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher <[email protected]
> <mailto:[email protected]>> wrote:
> Apologies for not starting off with system info: macOS Sierra (10.12.0),
> Xcode 8.0 (from the App Store).
>
> I'll try with Xcode 8.1 beta this afternoon and report back. Ill also open a
> ticket for improving -debug-time-function-bodies if I can confirm anything.
>
> Thanks!
>
> Ben
>
> On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hello! I work with a large project (~900 .swift files and more .m files). We
>> have a nightly job that compiles the app and calls out function bodies
>> (using -debug-time-function-bodies) that are slower than 100ms to compile.
>> Since upgrading to Swift 3, the number of trouble function bodies has one
>> from > 150 to < 20, so we're really happy about that! The only issue though
>> is that build time overall increased by ~1 min (amount of time to build all
>> targets before automatically merging to master in our integration build).
>
> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or with
> one of the toolchain builds from swift.org <http://swift.org/>?
>
> Xcode 8.1 beta 2 includes some type checker performance improvements which
> might have an impact here.
>
>>
>> To dig into this further, we've started a new nightly job that builds the
>> app using the -debug-time-compilation flag, and using that we've found that
>> some files take as long as 2-3 seconds to compile. But, there's no targeted
>> output to help us get this down via the -debug-time-function-bodies flag
>> (i.e. no function bodies that we can refactor to get compile times much
>> faster).
>
> One thing to look out for here is that I believe there are some cases where
> -debug-time-function-bodies isn’t reporting type checking time. >From my
> (potentially faulty) recollection, things like let bindings with literals or
> closures on the right hand side do not show up in the
> -debug-time-function-bodies output, and depending on the specifics of the
> expression these can sometimes take a long time to type check. When these
> appear within the body of another type declaration they can end up getting
> type checked multiple times during a full project build, and that time can
> add up.
>
> I don’t believe there is a bug open for improving -debug-time-function-bodies
> to help diagnose this, but opening a bug would be appreciated if you can
> confirm that this is the case, and of course patches to fix it are definitely
> welcome as well.
>
> Mark
>
>> We can see that most of the time is spent in "Type checking / Semantic
>> analysis" for these problem files, but we don't currently have any way of
>> knowing what that means. It feels like we've exhausted the available options
>> at this point (unless there are other flags I'm missing) in terms of
>> existing actionable debugging/profiling/reporting, so now our question is
>> this: what kind of reports would Swift maintainers be interested in seeing
>> in terms of output from profiling tools, etc. to help debug/diagnose these
>> slow compile issues? We're willing to devote time to tooling to help
>> generate such reports and file bugs.
>>
>> Thanks!
>>
>> Ben
>> _______________________________________________
>> swift-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-dev
>> <https://lists.swift.org/mailman/listinfo/swift-dev>
>
>
>
>
> --
> -Ben
>
>
>
> --
> -Ben
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
