Open AliSoftware opened 5 years ago
I am a little curious why your rearrangement helped in any significant way, since most of the time spent in the first expression is probably not actually about the expression itself, but about loading information about SIMD4 from the standard library. cc @xedin
I don't believe that this is related to expression type-checker because all of the expressions would exhibit the same performance since there is no cross expression caching.
@xedin do you need me to provide additional debug output then, like try with some other frontend flag that would show deeper drill-down of timings and better highlight where the bottleneck would be?
@slavapestov Since you have been working in that area, any ideas how to narrow this down?
I'll take a closer look soon, but trying out -trace-stats-events together with -stats-output-dir might be interesting.
Environment
Swift 5.0.1 (Xcode 10.2.1) and Swift 5.1 (Xcode 11b4)Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: bef33b731cca360caa4ab12a6f7f2937Issue Description:
Given the following code (whole code from file named
GLK+SIMD.swift
), the firstlet line1
takes \~ 70-100ms to type-check – while the remainingline2-4
take \~ 0.12ms.This even seems to have worsen between Swift 5.0.1 and 5.1
Demo code
Results
Swift 5.0.1
Swift 5.1
Switching to use the
init( x:y:z:w: )
instead ofinit( _:_:_:_: )
doesn't seem to help.What's strange is that the long type-checker time affects the first line but not the following ones that have the exact same structure (or is it some caching in action?)
Workaround by rearranging the code
The only workaround I found to reduce the type-checking time to way more reasonable values is to build a reference to the init function first, and then use it:
Swift 5.0.1
Swift 5.1
It seems it led to a lot better timings on Swift 5.0.1 (resolution of
init
reduced to 1.65ms), but is still at 20ms on Swift 5.1 (despite all the hints we give to the type-checker in the code) so there might be some regression there too.Footnote: It's worse (150ms) in the context of a bigger Xcode project
The initial code I posted at the top of this issue sometimes took >150ms when built in the context or our big project in Xcode 10.2.1 – triggering our
-Xfrontend -warn-long-expression-type-checking=150
warning.I haven't found any
extension float4
orextension SIMD4
in our own codebase that would declare moreinit
overloads and could explain the additional time it took in the context of our big project. We have external dependencies though so maybe they were the ones defining additional overloads, but Cmd-Clicking thefloat4.init
didn't show any overload other than the official one (the same that I've now extracted inmakef4
)But even once extracted to only compile that single from our big project directly using
swiftc
from the Terminal, the time taken by the type-checker seems curiously long.