https://kotlinlang.org logo
Join Slack
Powered by
Hey All :wave: We are currently trying to integrat...
# touchlab-tools
d
Hey All đź‘‹ We are currently trying to integrate SKIE, while it works great, it unfortunately brings our incremental compilation time from 160 seconds to ~800. We have not enabled default arguments and i believe docs say they are disabled by default and are sometimes the cause of long times. We are on the latest version of SKIE (0.5.2) and on Kotlin 1.8.10 Any thoughts?
âž• 2
f
Hi! Such an increase in compilation time is certainly not expected. Unfortunately, it’s difficult to estimate what is the cause without having access to the project in question. However, there are a few things that you can do on your end to help us find what’s going on. First one is to add the following configuration to your gradle:
Copy code
skie {
    debug {
        printSkiePerformanceLogs.set(true)
    }
}
And then send us the console output. Second, how many lines of code is in your Obj-C header file (with and without SKIE) and how big is the produced framework (again with and without SKIE)? Additionally, you can try globally disabling features one by one to see how the compilation time and other metrics change.
Also is the time for a single framework or are you building frameworks for multiple architectures at once? (I’d recommend doing all these experiments with a single framework, just to make it easier and faster)
d
let me get my iOS counterpart in this chat rather than playing telephone
its just for simulator
Copy code
Showing Recent Messages
FixLibrariesShortNamePhase: 0.000286s

ClassExportAnalyticsPhase: 0.000771s

ExtraClassExportPhase: 1.937294s

VerifyMinOSVersionPhase: 0.000242s

DefaultArgumentGenerator: 0.514163s

SuspendGenerator: 0.563612s

DeclareMissingSymbolsPhase: 0.001677s

KotlinIrAnalyticsPhase: 1.516341s

GenerateIrPhase: 0.612150s

RemoveKonanManglingPhase: 0.793962s

RenameNestedTypesConflictingWithExternalTypesPhase: 0.016154s

RenameNestedKotlinTypesConflictingWithKeywordsPhase: 0.002415s

RenameSkieNamespacesConflictingWithKeywordsPhase: 0.003277s

RenameTypesConflictingWithKotlinModulePhase: 0.012221s

KotlinRuntimeHidingPhase: 0.001407s

SwiftRuntimeGenerator: 0.000862s

ExtraClassExportPhase.FinalizePhase: 0.000159s

DefaultArgumentGenerator.FinalizePhase: 0.000003s

FlowBridgingConfigurator: 0.009628s

FlowMappingConfigurator: 0.069170s

SuspendGenerator.KotlinBridgeConfigurationPhase: 0.000055s

ExhaustiveEnumsGenerator: 0.011225s

SealedInteropGenerator: 0.026076s

MoveBridgesToTopLevelPhase: 0.001446s

RenameTypesConflictsWithOtherTypesPhase: 0.039730s

FixCallableMembersConflictsPhase: 4.644902s

FlowConversionConstructorsGenerator: 0.003818s

ExhaustiveEnumsGenerator.MembersGeneratorPhase: 0.206738s

SuspendGenerator.SwiftBridgeGeneratorPhase: 0.001643s

TemporarilyRenameTypesConflictingWithExternalModulesPhase: 0.020925s

DeleteSkieFrameworkContentPhase: 0.003833s

FixHeaderFilePropertyOrderingPhase: 0.023348s

AddLambdaTypeArgumentErrorTypePhase: 0.017215s

ApiNotesGenerationPhase.ForSwiftCompilation: 1.808680s

AddForwardDeclarationsPhase: 0.012015s

AddTypeDefPhase: 0.009891s

GenerateSirFileCodePhase: 0.500457s

WriteSirFileContentToDiskPhase: 0.668182s

GenerateFakeObjCDependenciesPhase: 0.002597s

SwiftCacheSetupPhase: 0.020308s

DisableWildcardExportPhase: 0.000334s

CompileSwiftPhase: 605.885874s

TemporarilyRenameTypesConflictingWithExternalModulesPhase.RevertPhase: 0.003460s

ApiNotesGenerationPhase.ForFramework: 0.476117s

LogSkiePerformanceAnalyticsPhase: 0.000220s
CompileSwiftPhase
looks like the prob
f
yeah, this phase compiles the generated code so it’s likely to be the one contribution the most. Good news is that we have accounted for basically all the increase in compilation time so now it’s just about figuring out why the Swift compilation takes so much time There are basically three options: • An insane amount of Swift code gets generated (Swift code compiles generally much faster than Kotlin, so it would have to be a lot of code). You can take look into the “build/skie/$framework/$arch/swift/generated” directory which contains all the generated code. Do you have some easy way to measure the number of lines and number of files (for example a statistics plugin in IDEA)? Knowing that would help a lot. • The compiler runs out of system resources - especially RAM. (Activity monitor should be enough to verify that). On that note, what Mac do you have? • The generated Swift code is for some reason difficult to compile (we’ve encountered similar problem before, where just 10 weird functions could increase compilation time by 100 s). This is the most difficult option for debugging so I’d leave that after we eliminate the first two
d
so first With SKIE Header File: 55716 lines at 176MB Without SKIE Header File 49994 lines at 147MB
are you looking for line count just in the generated files or our entire project?
f
mainly in the generated files, but if you can measure the project as well (separately) that would also be helpful
d
alrighty, on it
while we figure out how to get line counts on all these.. Should we be seeing swift files generated for classes which are not sealed classes? It looks as though every data object we have in kotlin has a corresponding swift file
f
yeah that’s expected, every exported class has a corresponding swift file - but most should contain basically just a typealias
d
correct ok
75823 is the generated line count
f
and do you know how many files it created?
d
4433
f
75 KLOC / 4,5k classes is not nothing, but it shouldn’t take 600s to compile, so pure volume isn’t likely the problem. So next step would be to verify if the compiler has enough resources - just run the compilation again and look at the activity monitor. We want to know if the system itself has enough free RAM and how much is allocated to the Swift compiler process also during the 600 s window this process should utilize all the cores
d
we have m1 Max machine with 64 GB ram
so it shouldnt be a problem
but we shall check
f
yeah, that should be good system-wise however, the compiler might still not have enough RAM due to a misconfiguration (which is usually a problem with the Kotlin compiler, but just to be sure we should rule that out)
Hi! I think I was able to reproduce at least part of the problem. I found a bug in 0.5.+ that might account for about 300 s, unfortunately that means we probably have another problem that causes the remaining +- 300 s Just to verify that assumption could you please try SKIE 0.4.20 to see if it makes a difference? Additionally, please try disabling all features using the following configuration (mainly with 0.5.2, but you can try the 0.4.20 as well):
Copy code
skie {
    features {
        coroutinesInterop.set(false)
        group {
            DefaultArgumentInterop.Enabled(false)
            SealedInterop.Enabled(false)
            EnumInterop.Enabled(false)
            SuspendInterop.Enabled(false)
            FlowInterop.Enabled(false)
        }
    }
}
s
Hello....I am working with @Dmitriy Tarasevich on this on the iOS side
I just reset the version to 0.4.20 and the times improved for sure
here is the console output
Copy code
Showing Recent Messages
Class Exporting Phase: AnalyticsPhase: 3.78334E-4s

Class Exporting Phase: VerifyMinOSVersionPhase: 2.583E-6s

Class Exporting Phase: ExtraClassExportPhase: 1.760813542s

Class Exporting Phase: GenerateIrPhase: 2.25E-6s

Class Exporting Phase: IrValidator: 2.291E-6s

Class Exporting Phase: KotlinRuntimeHidingPhase: 1.708E-6s

Class Exporting Phase: FlowBridgingConfigurator: 1.75E-6s

Class Exporting Phase: FlowConversionConstructorsGenerator: 1.458E-6s

Class Exporting Phase: FlowMappingConfigurator: 1.709E-6s

Class Exporting Phase: SwiftRuntimeGenerator: 2.042E-6s

Class Exporting Phase: SealedInteropGenerator: 4.333E-6s

Class Exporting Phase: DefaultArgumentGenerator: 1.833E-6s

Class Exporting Phase: ExhaustiveEnumsGenerator: 6.67E-7s

Class Exporting Phase: SuspendGenerator: 1.5E-6s

Class Exporting Phase: TypeAliasGenerator: 2.833E-6s

ObjC Phase: AnalyticsPhase: 9.50958E-4s

ObjC Phase: VerifyMinOSVersionPhase: 4.26917E-4s

ObjC Phase: ExtraClassExportPhase: 6.167E-6s

ObjC Phase: GenerateIrPhase: 6.625E-6s

ObjC Phase: IrValidator: 0.011861625s

ObjC Phase: KotlinRuntimeHidingPhase: 2.26209E-4s

ObjC Phase: FlowBridgingConfigurator: 1.19417E-4s

ObjC Phase: FlowConversionConstructorsGenerator: 1.21166E-4s

ObjC Phase: FlowMappingConfigurator: 1.02166E-4s

ObjC Phase: SwiftRuntimeGenerator: 0.002548458s

ObjC Phase: SealedInteropGenerator: 2.35083E-4s

ObjC Phase: DefaultArgumentGenerator: 0.475480209s

ObjC Phase: ExhaustiveEnumsGenerator: 3.37E-4s

ObjC Phase: SuspendGenerator: 0.551482625s

ObjC Phase: TypeAliasGenerator: 1.0E-4s

IR Phase: AnalyticsPhase: 1.237448792s

IR Phase: VerifyMinOSVersionPhase: 1.0334E-5s

IR Phase: ExtraClassExportPhase: 2.0E-6s

IR Phase: GenerateIrPhase: 0.666867584s

IR Phase: IrValidator: 2.917E-6s

IR Phase: KotlinRuntimeHidingPhase: 1.583E-6s

IR Phase: FlowBridgingConfigurator: 1.416E-6s

IR Phase: FlowConversionConstructorsGenerator: 1.458E-6s

IR Phase: FlowMappingConfigurator: 1.459E-6s

IR Phase: SwiftRuntimeGenerator: 1.333E-6s

IR Phase: SealedInteropGenerator: 1.5E-6s

IR Phase: DefaultArgumentGenerator: 1.584E-6s

IR Phase: ExhaustiveEnumsGenerator: 6.66E-7s

IR Phase: SuspendGenerator: 4.58E-7s

IR Phase: TypeAliasGenerator: 1.5E-6s

Linking Phase: RemoveKonanManglingPhase: 1.03167E-4s

Linking Phase: RenameEnumRawValuePhase: 1.30625E-4s

Linking Phase: FixCallableMembersConflictsPhase: 1.11708E-4s

Linking Phase: FixTypeConflictWithFrameworkNamePhase: 7.4292E-5s

Linking Phase: FixTypesConflictsPhase: 6.7458E-5s

Linking Phase: FixNestedBridgedTypesPhase: 2.0075E-4s

Linking Phase: FixHeaderFilePropertyOrderingPhase: 0.036492958s

Linking Phase: AddLambdaTypeArgumentErrorTypePhase: 0.034026208s

Linking Phase: RenameInaccessibleNestedDeclarationsPhase: 3.99333E-4s

Linking Phase: MangleTypesConflictingWithModulesPhase: 9.2875E-5s

Linking Phase: SkieModuleConfigurationPhase: 8.224356959s

Linking Phase: SwiftCompilationApiNotesGenerationPhase: 1.163981s

Linking Phase: AddForwardDeclarationsPhase: 0.028468916s

Linking Phase: AddTypeDefPhase: 0.021895708s

Linking Phase: DisableWildcardExportPhase: 0.00220975s

Linking Phase: GenerateSwiftCodePhase: 1.725542417s

Linking Phase: GenerateFakeObjCDependenciesPhase: 0.002443584s

Linking Phase: SwiftCacheSetupPhase: 0.026457792s

Linking Phase: CompileSwiftPhase: 59.437959583s

Linking Phase: RevertTypeManglingResultingFromConflictWithModulesPhase: 3.19541E-4s

Linking Phase: SkieModuleConfigurationPhase: 2.4542E-5s

Linking Phase: FinalApiNotesGenerationPhase: 0.517247875s

Interop library /Users/stevensmith/work/fbg-kmp-sdk/multiplatform/integrations/integration-launch-darkly/build/classes/kotlin/iosSimulatorArm64/main/cinterop/integration-launch-darkly-cinterop-carthageLaunchDarkly can't be exported with -Xexport-library



> Task :multiplatform:sdks:sportsbook-sdk:skieUploadAnalyticsDebugFrameworkIosSimulatorArm64

> Task :multiplatform:sdks:sportsbook-sdk:assembleDebugAppleFrameworkForXcodeIosSimulatorArm64



> Task :multiplatform:sdks:sportsbook-sdk:embedAndSignAppleFrameworkForXcode

/Users/stevensmith/Library/Developer/Xcode/DerivedData/FanaticsSportsbook-gprieypmhmsbodggpzvnvpndhhzs/Build/Products/development_debug-iphonesimulator/SportsbookSharedWrapper.framework/Frameworks/SportsbookShared.framework/SportsbookShared: replacing existing signature



BUILD SUCCESSFUL in 4m 19s

2023 actionable tasks: 9 executed, 7 from cache, 2007 up-to-date

KM Gradle Build passed.

KM Framework Path: ../../multiplatform/sdks/sportsbook-sdk/build/xcode-frameworks/development_debug/iphonesimulator16.4
Here is 0.4.2. with everything disabled above as you specified
Copy code
Showing Recent Messages
Class Exporting Phase: AnalyticsPhase: 7.0459E-5s

Class Exporting Phase: ExtraClassExportPhase: 0.041963708s

Class Exporting Phase: GenerateIrPhase: 2.25E-6s

Class Exporting Phase: IrValidator: 2.0E-6s

Class Exporting Phase: KotlinRuntimeHidingPhase: 1.667E-6s

Class Exporting Phase: SealedInteropGenerator: 1.667E-6s

Class Exporting Phase: DefaultArgumentGenerator: 1.542E-6s

Class Exporting Phase: ExhaustiveEnumsGenerator: 4.16E-7s

Class Exporting Phase: TypeAliasGenerator: 1.541E-6s

ObjC Phase: AnalyticsPhase: 8.15209E-4s

ObjC Phase: ExtraClassExportPhase: 3.667E-6s

ObjC Phase: GenerateIrPhase: 2.25E-6s

ObjC Phase: IrValidator: 0.015456125s

ObjC Phase: KotlinRuntimeHidingPhase: 2.50042E-4s

ObjC Phase: SealedInteropGenerator: 1.23458E-4s

ObjC Phase: DefaultArgumentGenerator: 0.524845833s

ObjC Phase: ExhaustiveEnumsGenerator: 3.03333E-4s

ObjC Phase: TypeAliasGenerator: 1.03459E-4s

IR Phase: AnalyticsPhase: 1.087820125s

IR Phase: ExtraClassExportPhase: 9.375E-6s

IR Phase: GenerateIrPhase: 0.790594291s

IR Phase: IrValidator: 3.666E-6s

IR Phase: KotlinRuntimeHidingPhase: 1.708E-6s

IR Phase: SealedInteropGenerator: 2.959E-6s

IR Phase: DefaultArgumentGenerator: 1.708E-6s

IR Phase: ExhaustiveEnumsGenerator: 7.5E-7s

IR Phase: TypeAliasGenerator: 1.875E-6s

Linking Phase: RemoveKonanManglingPhase: 1.21E-4s

Linking Phase: RenameEnumRawValuePhase: 1.38917E-4s

Linking Phase: FixCallableMembersConflictsPhase: 9.825E-5s

Linking Phase: FixTypeConflictWithFrameworkNamePhase: 7.0583E-5s

Linking Phase: FixTypesConflictsPhase: 6.825E-5s

Linking Phase: FixNestedBridgedTypesPhase: 2.03834E-4s

Linking Phase: FixHeaderFilePropertyOrderingPhase: 0.016574459s

Linking Phase: AddLambdaTypeArgumentErrorTypePhase: 0.011975625s

Linking Phase: RenameInaccessibleNestedDeclarationsPhase: 4.18416E-4s

Linking Phase: MangleTypesConflictingWithModulesPhase: 1.04708E-4s

Linking Phase: SkieModuleConfigurationPhase: 6.597522708s

Linking Phase: SwiftCompilationApiNotesGenerationPhase: 1.207040125s

Linking Phase: AddForwardDeclarationsPhase: 0.025628625s

Linking Phase: AddTypeDefPhase: 0.011531834s

Linking Phase: DisableWildcardExportPhase: 0.002330958s

Linking Phase: GenerateSwiftCodePhase: 0.312156667s

Linking Phase: GenerateFakeObjCDependenciesPhase: 0.001969s

Linking Phase: SwiftCacheSetupPhase: 0.026465917s

Linking Phase: CompileSwiftPhase: 3.513153958s

Linking Phase: RevertTypeManglingResultingFromConflictWithModulesPhase: 2.83E-4s

Linking Phase: SkieModuleConfigurationPhase: 2.0333E-5s

Linking Phase: FinalApiNotesGenerationPhase: 0.437863333s

/Users/stevensmith/work/fbg-kmp-sdk/multiplatform/sdks/sportsbook-sdk/src/commonMain/kotlin/com/betfanatics/sportsbook/shared/sdk/debug/BetErrors.kt:9:5: With old Native GC, variable in singleton without @ThreadLocal can't be changed after initialization

Interop library /Users/stevensmith/work/fbg-kmp-sdk/multiplatform/integrations/integration-launch-darkly/build/classes/kotlin/iosSimulatorArm64/main/cinterop/integration-launch-darkly-cinterop-carthageLaunchDarkly can't be exported with -Xexport-library



> Task :multiplatform:sdks:sportsbook-sdk:skieUploadAnalyticsDebugFrameworkIosSimulatorArm64

> Task :multiplatform:sdks:sportsbook-sdk:assembleDebugAppleFrameworkForXcodeIosSimulatorArm64



> Task :multiplatform:sdks:sportsbook-sdk:embedAndSignAppleFrameworkForXcode

/Users/stevensmith/Library/Developer/Xcode/DerivedData/FanaticsSportsbook-gprieypmhmsbodggpzvnvpndhhzs/Build/Products/development_debug-iphonesimulator/SportsbookSharedWrapper.framework/Frameworks/SportsbookShared.framework/SportsbookShared: replacing existing signature



BUILD SUCCESSFUL in 3m 5s

2022 actionable tasks: 7 executed, 6 from cache, 2009 up-to-date

KM Gradle Build passed.

KM Framework Path: ../../multiplatform/sdks/sportsbook-sdk/build/xcode-frameworks/development_debug/iphonesimulator16.4
let me know if you want me to try this with 0.5.2
f
Hm, the improvement of “CompileSwiftPhase” is more significant than I expected which means that this is likely just a single bug and not two. The good news is that we already have an internal build that seems to fix this issue. So we should be able to release it soon. I’ll let you know once that happens so that you can retest it. The bad news is that the remaining 60 s in the 0.4.20 is most likely not a bug that we could easily fix on our end. We usually see about 20-30 % increase in compilation time. So given the 3 minute baseline, the extra minute doesn’t look like that suspicious. However, you might be able to bring the compilation time down by reducing the amount of generated code via SKIE configuration. It’s likely that you don’t call most of the Kotlin code directly from Swift so selectively disabling SKIE when it’s not needed will help a lot. I’d also recommend starting by reducing the number of exported classes to Swift in general. That can significantly speed up the compilation time and reduce binary size even without SKIE. The first place to look at is for things like “transitiveExport” or “export” functions in the Gradle file and making sure that you only export the modules that contain code that is directly called from Swift. Making declarations (that are not called from other modules) internal will also prevent them from being exported. We often see that projects explicitly export whole modules (which can be configured in Gradle) even though they don’t need to directly call that code from Swift
s
great...thanks....any timelines on when the next version will be released?
also....what do we give up by using 0.4.20 for now until the fixed version comes out?
f
what do we give up by using 0.4.20
Everything important should be mentioned here https://skie.touchlab.co/category/change-log
any timelines on when the next version will be released
I hope that tomorrow - early next week at the latest.
s
Thanks
f
Hi! The new release (0.5.3) is out, so please give it a try and let me know if it solved the issue.
K 1
🎉 1
d
@Steve Smith
s
will give a try later this morning
thanks
d
Thanks Filip!
s
@Filip DolnĂ­k - based on my testing it looks like the issue is resolved and the build times seem about 10-20% above non SKIE builds
f
Great! Thanks for your help with debugging.
s
thanks for the support
9 Views
Open in Slack
PreviousNext
Powered by