https://kotlinlang.org logo
Join SlackCommunities
Powered by
Well, adding one 40-line kotlin file, and one 4kb ...
# kotlin-native
v
Well, adding one 40-line kotlin file, and one 4kb C-library, increased compilation times of this project https://github.com/v79/WaveShareTests/tree/libbmp from about 3.5minutes to 1 hour 40 minutes.
👀 2
a
What computer do you use? Old laptop build ~ 1000 lines native code on 20 minutes
v
It's not a particularly modern machine - Intel i5-6500, 16Gb of RAM - but the issue is the build time increasing from ~3.5 minutes to 1h40m just by adding a tiny bit of extra Cinterop code. That's just wrong, on any machine.
m
Are you sure it's reproducible?
v
I tried this on Windows and on an Ubuntu vm. I must have something wrong with my .a file, but no errors or warnings.
a
Hi, @v79! I can also see a time increase, not sure about the cause. Could you please report it at kotl.in/issue ? Just to make it easier to track.
a
The first time build will be download a lot of files from the internet. The second build must be faster
a
This is not about the download, as far as I can see.
v
There's no disc activity that I can see during that entire time. There are no extra packages included, just this single C library I compiled on my Pi and included in the project. Compare the branch with master if you want to see how little has changed.
k
If you didn't change your default mx heap, you're probably spending most of that time garbage collecting...
v
https://youtrack.jetbrains.com/issue/KT-43475 raised; another build attempt took 1h41m.
n
If you have access to a real Linux desktop/laptop (not Linux running in a VM) then try doing the same thing, and see if the compilation times are quicker. Linux is known in many cases to be much more efficient at compiling software than Windows. I know of one case where an Embedded software developer was able to cut down compilation times by over 50% just by compiling the software on Linux instead of on Windows.
Normally the CPU is the bottleneck in software compilation, however file I/O (including the file system, internal storage hw etc) can in some cases heavily affect software compilation.
v
I moved the project to my SSD. That shaved about 2 minutes off the compilation time. Whatever is going wrong, it's not my hardware.
m
As mentioned above - maybe it's jvm heap issue. Does adding 
org.gradle.jvmargs=-Xmx2g
to 
gradle.properties
change anything?
s
We are investigating the problem. It seems that it is an LLVM bug, which causes it to spend a lot of time optimizing some particular code. More details will follow.
m
Well - maybe it's time to move LLVM from 8.0 to current 11.0 ? 😁
s
Somewhat unrelated until it becomes clear that this is known issue and is fixed in LLVM 11.
a
The problem is about release build’s optimizations. @v79 as a workaround, you can try adding this to the `build.gradle.kts`:
Copy code
binaries {
            executable("waveshare") {
                this.optimized = false
                entryPoint = "org.liamjd.pi.main"
            }
        }
or use a debug build.
v
Thank you @Artyom Degtyarev [JB], disabling optimization fixed it. Back down to 3 minutes to build. And the executable is smaller, too, which is a win.
s
Well - maybe it’s time to move LLVM from 8.0 to current 11.0 ?  😁
JFTR: we’ve checked, using LLVM 11.0 doesn’t seem to help 🙂
One more possible workaround — use 
immutableBlobOf
instead of 
ubyteArrayOf
in 
BitmapData.gImage_2in7b_Black
.
8 Views
Open in Slack
PreviousNext
Powered by