Kotlin-native: Slow compilation time

[RUSshy]

Hi

When compiling even hello world i expect to be fast, but it is really slow

Is there something i am missing when compiling? i followed this https://github.com/JetBrains/kotlin-native/blob/master/README.md

[vvlevchenko]

How can we reproduce your measurements?

[RUSshy]

I don't have numbers, but it is over usage, it is just much slower compared to other languages such as C++/Swift or even GO

[RUSshy]

it takes 6 seconds to compile this:

fun main(args: Array<String>)
{
   println("hello")
}

command: kotlinc hello.kt -o hello
platform: windows 10 x64

it should be instant

[vvlevchenko]

could you please share your code for c++/swift, go, versions of compilers and time <command> results?

[RUSshy]

I'm on windows i don't know alternative for time command, i found this on google:

cmd /v:on /c "echo !TIME! & *mycommand* & echo !TIME!"

λ cmd /v:on /c "echo !TIME! & kotlinc hello.kt -o hello & echo !TIME!"
21:44:20,30
KtFile: hello.kt
21:44:26,01

as you can see 5:30 seconds, almost same thing i counted using head

for c++ i don't have toolchain installed so i use built in with clion
c++:
mingw 5
cmake 3.7.2
gdb 7.11.1

this code took ~1-2 seconds to compile and run

#include <iostream>

int main()
{
    printf("hello");
    return 0;
}

cmake_minimum_required(VERSION 3.7)
project(untitled)

set(CMAKE_CXX_STANDARD 11)

set(SOURCE_FILES main.cpp)
add_executable(untitled ${SOURCE_FILES})

[vvlevchenko]

thank you for reporting.

[RUSshy]

Swift (Windows mingw port): https://github.com/tinysun212/swift-windows

code:

print("hello")

command: swiftc Hello.swift
command for timing: /v:on /c "echo !TIME! & swiftc Hello.swift & echo !TIME!"

result:
22:05:27,32
22:05:27,58

It is instant

[RUSshy]

Any idea on this? it is slow for you too? this is annoying to wait each time i want to change a constant value

[RUSshy]

for d lang:

code:

import std.stdio;

void main()
{
    writeln("hello");
}

command: dub build
command for timing: cmd /v:on /c "echo !TIME! & dub build & echo !TIME!"

result:

16:01:23,51
Performing "debug" build using dmd for x86.
t ~master: building configuration "application"...
Linking...
16:01:24,31

0.4 second only

[RUSshy]

for rust:

code:

fn main() 
{
    println!("hello");
}

command: cargo build
command for timing: cmd /v:on /c "echo !TIME! & cargo build & echo !TIME!"

result:

16:07:00,84
   Compiling hello_world v0.1.0 (file:///C:/Users/RUSshy/dev/rust/hello_world)
    Finished dev [unoptimized + debuginfo] target(s) in 0.32 secs
16:07:01,39

0.55 second only (0.32 from cargo info)

[r4zzz4k]

Mate, you do understand that you are following the development of pre-release software, right? That developers are working on core features, and you are talking about not-that-important at this stage performance? You can revisit #670, where devs themself mentioned that the compiler isn't ready for performance comparisons with other tools (some of which, among those you mentioned, are passed their first release decades ago).

If you've followed Kotlin development itself, you may know that at some point developers started trying to hold on-par both compiler speed and feature-richness of language and toolset, so you can rest assured that as soon as core of Kotlin/Native is done, team will definitely work on performance. Till this point I don't see any reasons to bother them with constantly opening issues on this topic, of which tour's is the third one already, if I recall correctly.

Sorry if I sound mean, you just seem a bit ignorant. It's open-source, you see. If you're picking a tool for you right now to use in production, you should definitely go with something more mature than Kotlin/Native. If you're following development process just for fun, you can either work on pull request to help devs with this issue, or just wait whey they have time to tackle with it themselves. As for priorities, I'm personally more interested in seeing exporting symbols to outside world, so in my opinion you shouldn't try to force developers change their priorities based on your opinion and just let them do their job.

Once again, didn't mean to sound offensive at all, sorry if anything.

[RUSshy]

I just wanted to give feedback, and to know if they are aware of it, just that, but i think you are right it is too early, i want kotlin native to be successful this is why i opened this issue about this concern

[RUSshy]

https://twitter.com/scala_native/status/893192456002469888

scala native achieved compilation under 1 second, i hope to see same for kotlin native soon

[RUSshy]

What is your plan for this issue?

[eugene-nikolaev]

Let me put my 2 cents in:

> kotlin -version
Kotlin version 1.1.51 (JRE 1.8.0_144-b01)

> uname -a
Linux lin-pc 3.19.8-031908-generic #201505110938 SMP Mon May 11 13:39:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

time kotlinc hello.kt

real    0m2.050s
user    0m4.504s
sys 0m0.132s

time javac Test.java 

real    0m0.385s
user    0m0.764s
sys 0m0.056s



md5-39fe736bfd8446a0b6c771170bd69106



fun main(args : Array<String>) { 
  println("Hello, world!") 
}



md5-e1d04da232b5cf88344251237e0e8632



class Test {
  public static void main(String[] args) {
     System.out.println("Hello, world!");
  }
}

Mate, you do understand that you are following the development of pre-release software, right? That developers are working on core features, and you are talking about not-that-important at this stage performance?

Sure, I think the most of people understand this.

But IMHO we should start at least to notice it as soon as possible.
Otherwise, there is a chance the JRuby history will repeat itself.
Its startup time is far more slow that e.g. compared with the groovy which is similar enough.
And the time is being degraded significantly depending on the app size/dependencies number.

Also it is very important for TDD. Which is needed now.
TDD with JRuby is really a pain and I'd like to avoid that with Kotlin which seems very interesting.

P.S. Core i3@3800Mhz (full desktop, not a mobile version), 16GB RAM, SSD.
Linux Mint 17.2

[4ntoine]

I can confirm hello world compilation takes ~6 seconds for me (MBP2016, 16Gb RAM, SSD, macos 10.12.6

~/Documents/dev/src/kotlin-native asmirnov$cat ./hello.kt
fun main(args: Array<String>) {
    println("Hello world")
}
~/Documents/dev/src/kotlin-native asmirnov$time kotlinc hello.kt
KtFile: hello.kt

real    0m6.842s
user    0m11.109s
sys 0m0.698s

~/Documents/dev/src/kotlin-native asmirnov$java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

Let me know if i can help in any way

[RUSshy]

Any ETA for when this issue will get adressed? me an team are debating if we use xamarin or kotlin, but right now with compile time slow we can't choose it, but depending on progress we might accept trade off for few moment

[4ntoine]

v0.4:

~/Documents/dev/src/kotlin-native asmirnov$time kotlinc ./hello.kt -o ./hello
KtFile: hello.kt

real 0m6.696s
user 0m12.382s
sys 0m0.574s
~/Documents/dev/src/kotlin-native asmirnov$cat ./hello.kt
fun main(args: Array) {
println("Hello world")
}

[RUSshy]

With master and upgrade to clang 5, build is now 8seconds instead of previous 6seconds, so it is 2s slower :(

[RUSshy]

Any news on this?

[kennycason]

It's over 10 seconds for me :)

[DarrienG]

MBP 2014 maxed out, compilation of hello world takes 14 seconds for me.

$ time kotlinc test.kt
kotlinc test.kt  14.04s user 0.60s system 221% cpu 6.619 total

[RUSshy]

Project approaching v1.0 i hope this gonna be improved

[faob-dev]

@RUSshy i am running kotlinc on ubuntu running on virtual machine it is very slow

time kotlinc hello.kt

real 0m7.479s
user 0m10.492s
sys 0m1.104s

rust, c compiles very fast on ubuntu running on virtual machine please fix this issue

[RUSshy]

v0.8.0:

time kotlinc main.kt -o hello -opt   

real    0m6.521s
user    0m12.827s
sys 0m0.345s

[DarrienG]

Friend, you're compiling with JVM Kotlin. In that example you bundle everything into a Jar including the Kotlin runtime (which is like 2MB) which is why it takes a while.

Consider using Gradle for incremental compilation and you should see your build times drop to maybe a second or less.

You should still get 8+ second build times with the native compiler though.

[4ntoine]

@seieewkx Kotlin and Kotlin-native are different projects. This ticket is about Kotlin-native compile time.

[RUSshy]

v0.9

time ./kotlinc main.kt -o test -opt

real    0m10.684s
user    0m0.000s
sys     0m0.122s

It is much much worse than before..

Next version is 1.0, both compile speed and language performance should be the focus in my opinion, or people who waited for 1.0 to evaluate the language will have a really negative opition on it

[EhsanKia]

We're past 1.0 and this is still a big issue.

> .\kotlinc-native -version                         
info: kotlinc-native 1.3.0-rc-190 (JRE 1.8.0_191-b12)                              
Kotlin/Native: 1.0.2      

> Measure-Command { .\kotlinc-native .\hello.kt }                        
TotalSeconds      : 4.503814                                                 

This is again on a 3 line hello world program.

[ghost]

Please investigate into this. It feels like a eternity re-compiling my project because I've changed a const.

[RUSshy]

2019, let's hope this is the year of performance for every developpers in this sad world, we have better hardware than before but software is still regressing year after year

[abitgen]

For me when running in Kotlin Script file, it took more time. But when i use Intellij built in Kotlin REPL to run code, its actually fast.

[mgood7123]

Mate, you do understand that you are following the development of pre-release software, right? That developers are working on core features, and you are talking about not-that-important at this stage performance? You can revisit #670, where devs themself mentioned that the compiler isn't ready for performance comparisons with other tools (some of which, among those you mentioned, are passed their first release decades ago).

If you've followed Kotlin development itself, you may know that at some point developers started trying to hold on-par both compiler speed and feature-richness of language and toolset, so you can rest assured that as soon as core of Kotlin/Native is done, team will definitely work on performance. Till this point I don't see any reasons to bother them with constantly opening issues on this topic, of which tour's is the third one already, if I recall correctly.

Sorry if I sound mean, you just seem a bit ignorant. It's open-source, you see. If you're picking a tool for you right now to use in production, you should definitely go with something more mature than Kotlin/Native. If you're following development process just for fun, you can either work on pull request to help devs with this issue, or just wait whey they have time to tackle with it themselves. As for priorities, I'm personally more interested in seeing exporting symbols to outside world, so in my opinion you shouldn't try to force developers change their priorities based on your opinion and just let them do their job.

Once again, didn't mean to sound offensive at all, sorry if anything.

hai

[harsh183]

What I'm wondering is how something like kotlin server from the try kotlin website is working faster

0.04user 0.00system 0:01.98elapsed 2%CPU (0avgtext+0avgdata 12488maxresident)k
0inputs+0outputs (0major+997minor)pagefaults 0swaps

as compared to javac on my system.

1.71user 0.12system 0:00.74elapsed 245%CPU (0avgtext+0avgdata 74420maxresident)k
0inputs+72outputs (0major+14088minor)pagefaults 0swaps

```

[davaponte]

Almost TWO years later still the same problem:

time kotlinc-native hello.kt -o hello
real 0m10,309s
user 0m13,172s
sys 0m0,852s

kotlinc-native -version
info: kotlinc-native 1.3.50-dev-259 (JRE 1.8.0_212-8u212-b03-0ubuntu1.18.04.1-b03)
Kotlin/Native: 1.3-dev

uname -a
Linux ASUS-LAPTOP 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[RUSshy]

Is it on roadmap to fix this issue ? please comunicate, you've been silent on this one, it is the most commented issue..

[olonho]

Generally there are many activities aiming to improve compilation time on-going both in Kotlin/Native and in general Kotlin.
They include dead code elimination compiler analysis (on review), deserialization optimizations, frontend IR work and probably some other optimizations. Team is focused on compilation time improvements, stay tuned.

[Indribell]

Almost TWO years later still the same problem:

time kotlinc-native hello.kt -o hello
real 0m10,309s
user 0m13,172s
sys 0m0,852s

kotlinc-native -version
info: kotlinc-native 1.3.50-dev-259 (JRE 1.8.0_212-8u212-b03-0ubuntu1.18.04.1-b03)
Kotlin/Native: 1.3-dev

uname -a
Linux ASUS-LAPTOP 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

On a AMD 3900x, nvme, ECC ..

Its not too bad compared to basic Kotlin

0.1 Hello World, Warm ( Kotlin 1.3 )

real 0m2.106s
user 0m4.864s
sys 0m2.386s

0.2 Hello World, Warm ( kotlin-native 0.9.3 )
And yes, this is done with 0.9.3 because for some reason the Kotlin-Native snap for Ubuntu is not updated in the last year ( 29 September 2018 ).

real 0m4.305s
user 0m8.600s
sys 0m1.886s

Painful is not the right word ( this with warmup / already multiple compiles ).

For fun i ran Swift ( 5.1 ) on Linux:

1.1. Hello World, "Cold":

hello World
real 0m0.175s
user 0m0.009s
sys 0m0.113s

1.2. Hello World, Swift warmed up:

hello Worlds
real 0m0.018s
user 0m0.000s
sys 0m0.018s

1.3. Hello World, Compiled to file

real 0m0.088s
user 0m0.028s
sys 0m0.047s

2.1 Swift with Foundation and other stuff ( import foundation, classes, string manipulation, conditions, ... )

real 0m0.498s
user 0m0.218s
sys 0m0.235s

2.2 Swift with Foundation and other stuff "warmed up"...

real 0m0.133s
user 0m0.120s
sys 0m0.013s

2.3 Swift with Foundation and other stuff Compiled to file

real 0m0.153s
user 0m0.127s
sys 0m0.026s

The difference is ridiculous ... And both are using LLVM. Even Rust and Crystal only hit 0.5 for a basic "Hello World"s, and both are also LLVM backed languages. The amount of compile optimizing needed seems to be huge.

[RUSshy]

i warned 2 years ago about consequences, nobody listen to me, they see me as troll or someone who know nothing so they ignore my advices.. now they pay the price

be careful because there is work to make swift a crossplatform language, and C# gonna get swift and java interop next year for .net 5.0 + aot compilation with llvm too

there can't be adoption is you need wait 10 seconds to compile hello world or to change the value of a variable.. and there can't be trust if nothing changes in 2 years.. and it is not the only issue with KN..

[DarrienG]

To be fair, there are more reasons not to use Kotlin Native. It has a crazy memory model that decided it should pretend to be rust, but make those memory errors runtime errors rather than compile time errors. I don't know what everyone was thinking with KN. I just wanted to compile my Kotlin to native and it can barely even do that :(

[LouisCAD]

I have to admit Kotlin/Native painfully slow compilation time is my top reluctance to prototype ideas, which is required in order to consider making products with it.

I fear having to flip a Boolean when I'm building for Native, that doesn't encourage me to improve working code and taking on new challenges.

You can compare the compilation speed between Android and iOS targets in that module: https://github.com/LouisCAD/Splitties/tree/61508e16f9820f37b732acb868df6e45f2436db1/modules/preferences

Compiling for iOS, or even macOS is many times slower, and it multiplies further as I need to compile for x64, arm32 and arm64 to support down to iPhone 4S-5 and trying the final app in the simulator.

Please, make this your top priority for 1.3.70 or 1.4. If that implies having a slower/unoptimized runtime executable for debug builds, that's fine.

I can't sell Kotlin/Native to my colleagues or my boss when you have Dart that hot reloads in less than one second (Flutter), and allows to iterate and preview the whole thing so much faster than me waiting 1-2 minutes to flip a Boolean.

I personally don't dislike the saner concurrency movement although it's possible that it's currently not in its final form, but waiting so much time to see if your attempts fix the errors you're encountering, not talking about actual feature or APIs development… that sums up to a very hard experience for beginners, and even not so beginners.

[kpgalligan]

@LouisCAD Agree that compile times are slow, although I'd point out the team has said in multiple places that compile speed is something that will be worked on (see above). I don't know for sure, but I assume the grand compiler rewrite is a blocker on that.

As for Dart/Flutter, there's kind of a habit here where KN gets compared to other things and everybody expects it'll be the best at everything across the board. Dart/Flutter refresh is great. Dart/Flutter integration with existing apps/architecture is garbage. Pluses/minuses. Same thing when runtime performance is compared to JVM. The comparison should be a rewrite in Swift, which often has wildly different numbers. The (my?) general dev flow for Kotlin features is iterating on code in JVM, then compiling and integrating on iOS. If the primary dev flow is "edit a boolean, recompile, open in iOS, repeat" I'd say you need to change the flow for now at least. Flutter specifically is designed to be a UI toolkit (and that's it).

Not saying it's "fine", but there are plenty of teams making it work in production.

@DarrienG Not understanding the memory model doesn't make it "crazy". Everybody knows you can't edit the UI from a background thread. Same thing, more formal. Not liking it is a different discussion.

@RUSshy Pointing out slow compile times doesn't make you a troll. It's more the angry ranting.

For all the doom and gloom, adoption in prod is increasing significantly. My "job" is essentially talking to teams doing that. Compile times are a concern. Memory model is a concern (for new devs). People are using it.

[kpgalligan]

If we're on the subject of "what are teams worried about", by far the biggest concern is multithreaded coroutines. Just FYI. Well, that and "is this production ready?", which is not a binary question. Depends on the team.

[DarrienG]

The memory model is a huge divergence from how "standard" Kotlin works. A lot of Kotlin code written for JVM doesn't work for native. I've written quite a bit of Rust and also understand interacting with the UI thread vs other threads, but this is a big detractor from anyone just wanting to try out Kotlin Native with a pure Kotlin project.

If it were like Rust and it were a compile time error then I wouldn't have this complaint (although it would still a nuisance), but my Kotlin code that was working stops working in Native with a fresh new runtime error which is not a good experience.

Anyway I don't want to detract from the conversation about compile times too much. I'm out.

[RUSshy]

so i decided to give it a try again today, and.. it takes 26 seconds now..
3x slower than before, and it was already incredibly slow..

[LouisCAD]

@RUSshy Please, specify the used Kotlin/Native version that you used, for history purposes. Also, why did you close the issue? Was it a mistake?

[RUSshy]

Gradle: 5.5.1
Kotlin Multiplatform: 1.3.61

with latest 2019.3.1 IntelliJ IDEA Ultimate

That's a project i created directly from IntelliJ

plugins {
    id 'org.jetbrains.kotlin.multiplatform' version '1.3.61'
}
repositories {
    mavenCentral()
}
kotlin {
    // For ARM, should be changed to iosArm32 or iosArm64
    // For Linux, should be changed to e.g. linuxX64
    // For MacOS, should be changed to e.g. macosX64
    // For Windows, should be changed to e.g. mingwX64
    mingwX64("mingw") {
        binaries {
            executable {
                // Change to specify fully qualified name of your application's entry point:
               entryPoint = 'sample.main'
                // Specify command-line arguments, if necessary:
                runTask?.args('')
            }
        }
    }
    sourceSets {
        // Note: To enable common source sets please comment out 'kotlin.import.noCommonSourceSets' property
        // in gradle.properties file and re-import your project in IDE.
        mingwMain {
        }
        mingwTest {
        }
    }
}

// Use the following Gradle tasks to run your application:
// :runReleaseExecutableMingw - without debug symbols
// :runDebugExecutableMingw - with debug symbols

I closed it because it doesn't seems to be a concern for jetbrains

[Dominaezzz]

We're probably going to have to wait till 1.4, that's a reasonable time to give up.
Mind re-opening? I don't want them to forget (highly unlikely) or someone else to re-create this issue.

[raniejade]

Just adding another data point here, this project https://github.com/raniejade/godot-kotlin takes roughly 4 minutes on a clean build. Running the build again after changing a single line of code takes roughly 1 minute and some spare change, which is terribly slow. Hopefully 1.4 would bring some speed up :crossed_fingers:.

[LouisCAD]

Just adding for reference that there's been some improvements in 1.3.70, although many cannot use it as a bug affects kotlinx.coroutines which consequently has not been released with a compatible ABI for 1.3.70.

So, there's ongoing progress, which is encouraging.

[RUSshy]

Decided to give it a try and i get a huge gradle error

https://gist.github.com/RUSshy/e10dd31e869388e67b82fea6f4b8e59c

Using latest IntelliJ IDEA 2020.1 BETA

I hate gradle, between constant new versions breaking stuff, huge downloads, slow deamon startup, sluggish command line

I'm glad i don't do android development, gradle is not for me, all i want is a C++/GO/C# replacement for desktop/server development

Hopefully JB decide to provide standard toolset similar to Rust/GO for native stuff, why go overly complex for such simple task?

Why need IDE to download all the env?

Why is is still multi GB of files to get started?

Why everything is slow?

Year after year, new solutions are worst than those of the past, gradle is a mistake

[gnomeria]

JVM world really needs an upgrade in their toolings so bad. Even until now, I think kotlin is the most enjoyable and elegant language. But the slow compiler time, sluggish cli toolings, different linters/formatters, makes me cannot enjoy it anymore other than for Android app. Most modern languages nowadays provide a much more streamlined developer tools.

[RUSshy]

This issue is now 3 years old..

So how is the compilation today? let's see:

OS: Windows 10 x64
https://github.com/JetBrains/kotlin/releases/tag/v1.3.72

$ time ./kotlinc-native main.kt -o main

real    0m8.340s
user    0m0.061s
sys     0m0.090s

8.3 seconds.......

When i created this issue, it compiled hello world in 5.3 seconds, 3 YEARS layer, it is now 8.3 seconds.... on same machine

[Dominaezzz]

1.3.72 is pretty old now. You should be comparing with 1.4-M3 (Maybe even a preview version).

Also, 8.3 seconds is better than some of the other numbers, ideally you should have a graph of how performance has been changing over time.
Especially since the team only recently started focusing on compilation performance.
You should compare the performance now, to when they starting putting work into it, not just when you (and most of us) complained about it.

It's taken a while but it's a big project and a small team.

[raniejade]

In our project https://github.com/utopia-rise/godot-kotlin we can see a big difference in compile time between OSX (~2m30s+) and non-OSX machines (~3m10s+). Going from 1.3.7x to 1.4-rc, non-OSX compile times have increased from 20-30s - while in OSX there is no significant difference. (You can clearly see which platform is priority for KN).

But honestly, the real deal breaker for us is the lack of incremental compilation. We don't mind that the initial compile is longer, as long as the subsequent builds complete way faster. Unfortunately, a single line change still take approximately the same amount of time as a clean build.

[emresahin10]

My computer is begging me not to coding with kotlin. Such a shame

[SvyatoslavScherbina]

Hello.
First of all, I'd like to ask everyone to avoid being rude or offensive. Please behave yourselves. Otherwise it is quite hard for us to keep communicating.

During the past years we've been changing our compilation model and libraries format a lot, one of the goals was to achieve binary compatibility guarantees (see https://youtrack.jetbrains.com/issue/KT-42293). And this directly affects compilation time in a couple of ways.

• These changes prevented us from investing more time in compilation performance, because optimizations would complicate the evolution: the more your optimize the system, the more convoluted it becomes. In a way improving compilation time was a premature optimization.
• The changes to the compilation model themselves introduced some performance degradations. For example, at some moment of time we changed klib format from LLVM-bitcode-based to Kotlin-IR-based. This allowed the unrestricted evolution of code generation while keeping possibility for achieving stable ABI for libraries. But after this change the compiler was forced to compile all the dependencies from Kotlin IR to LLVM bitcode (including stdlib!). We are addressing this with compilation caches (see below), but this of course requires additional work. So what’s also important here is that the current compilation model itself makes it harder to have good compilation time. This is also different from Swift and somewhat different from C++, for example.

Anyway, by this moment for some time improving compilation performance is one of our main focuses. We are striving to improve the situation, please stay tuned.

As you may know, in 1.3.70 we've introduced two features for this: compilation caches and compiler daemon. Compilation caches are enabled only for macos_x64 and ios_x64 targets at the moment.

Both caches and daemon features are enabled only when compiling with Gradle. And compilation with Gradle will remain our main focus, because our observations show that most of Kotlin/Native users build with Gradle. Also it is often easier to optimize something in Gradle because it takes care of managing background warmed-up build processes, up-to-date checks, dependency resolution and other high-level build matters.

So measuring compilation time with command-line compiler doesn't make much sense. If your particular case actually requires compiling with command-line compiler, please share your use case with us ([email protected]).

Finally, we clearly understand that compilation time is one of the major pain points with Kotlin/Native at the moment.

I’m closing this ticket because we are migrating issue tracking to YouTrack and because it became too off-topic and unhealthy. Please watch https://youtrack.jetbrains.com/issue/KT-42294.

[leitao]

I have a dual socket Xeon machine (Thinkstation P720) and it is a shame that with the latest SDK, it takes 8 seconds to build a simple "hello world". This turns Kotlin impossible to use in my native project.

> Task :compileKotlinNative
w: /home/leitao/IdeaProjects/untitled/src/nativeMain/kotlin/main.kt: (11, 10): Parameter 'args' is never used

BUILD SUCCESSFUL in 8s

[SvyatoslavScherbina]

@leitao it is hard to confirm your results without knowing the actual steps you followed.

Here are my experiments on Intel Core i7-3770:

$ cat build.gradle.kts 
plugins {
    kotlin("multiplatform") version "1.4.31"
}

kotlin {
    linuxX64 {
        binaries {
            executable()
        }
    }
}
$ cat src/commonMain/kotlin/main.kt 
fun main() {
    println("Hello world")
}
$ ./gradlew clean linkDebugExecutableLinuxX64

> Configure project :
Kotlin Multiplatform Projects are an Alpha feature. See: https://kotlinlang.org/docs/reference/evolution/components-stability.html. To hide this message, add 'kotlin.mpp.stability.nowarn=true' to the Gradle properties.


BUILD SUCCESSFUL in 5s
4 actionable tasks: 3 executed, 1 up-to-date

Also, starting from 1.5.0 (M1) with experimental kotlin.native.cacheKind.linuxX64=static in gradle.properties:

$ ./gradlew clean linkDebugExecutableLinuxX64

> Configure project :
Kotlin Multiplatform Projects are an Alpha feature. See: https://kotlinlang.org/docs/reference/evolution/components-stability.html. To hide this message, add 'kotlin.mpp.stability.nowarn=true' to the Gradle properties.


BUILD SUCCESSFUL in 2s
4 actionable tasks: 3 executed, 1 up-to-date

(should be close to current compilation time on macOS).

Also please take a look at some tips to improve compilation time: https://kotlinlang.org/docs/native-improving-compilation-time.html

This issue is closed, please watch or comment https://youtrack.jetbrains.com/issue/KT-42294 instead.