Bug "compiling cpp for libil2cpp" takes much longer suddenly.

Hey,

I've been working on my project for a few years, using IL2CPP just fine. Build times for Android have always taken about 30secs on average. Though now suddenly all builds take up to 20mins, and 99% of the time is spend on "compiling cpp for libil2cpp".

And my CPU goes through the roof when it goes, bogs up my computer!

What I've tried based on other threads with roughly the same topics:
- Disabled BitDefender
- Deleted my project library
- Reinstalled Unity
- Reinstalled my IDE (Rider).

It does seem to be random though, very occasionally the build time will be 30 secs. Then the rest of the time about 15-20mins. And I'm not doing anything different, I've done some experiments to check before building each time, like editing some code in various scripts, editing prefabs, scenes etc... Though it just seems to be quite random as to when it needs to do the "compiling cpp for libil2cpp" for 20mins.

In my editor logs, all the files being compiled seem to be the same between my 30 sec builds and 20mins builds. The difference is the time spent on certain files. Basically all the files in "C_Android_arm64 Library/Bee/artifacts/Android/d8kzr" (like 50 files or so) take about 0-2secs each in the 30 secs build.
But in the 20mins build they average from 10secs to 180 secs!

Some of the threads about IL2CPP are years old, wondering if there's any clear solutions since then to solve builds taking so long? Especially that mine seems to be random, and out of the blue. Like... sometimes it uses the cache and othertimes it doesn't?

And to clarify again, this has never been an issue over the years. No matter if I make new scenes, make new scripts, import assets etc... The build time would barely take a few minutes the first time maybe, but then 30 secs most of the time.

Thanks!

 

2022.3.7f1

 

I had a look at the editor log in realtime for once. It really does the usual for the first 30secs, then just gets stuck on all the "C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/" files for the next 20mins, before getting to the build gradle part which takes about 10secs. Then it's complete.

It doesn't freeze or anything, it just goes through a huge amount of these .o files while pretty much using 100% of my CPU (i9-10850k), I can barely do anything else on my computer:

example:
--------------
1647/1673 18s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/vm8y7zb3ae6s.o
[1648/1673 3s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/1jqxnvpgc7em.o
[1649/1673 17s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/a3bskqtllyxi.o
[1650/1673 28s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/urefy0vhg78i.o
[1651/1673 26s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/qv10oc9wnpz5.o
[1652/1673 15s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/a97orr79qv03.o
[1653/1673 19s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/nitceoz6wb6z.o
[1654/1673 22s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/odnwnnfsri39.o
[1655/1673 15s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/a74asqx57pu9.o
[1656/1673 18s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/47dwone1gz66.o
[1657/1673 14s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/8nhx2jxqbfo4.o
[1658/1673 17s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/y0hwkm1uahhv.o
[1659/1673 30s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/yh5nbv70lt9v.o
[1660/1673 20s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/1nsqeziuzatc.o
[1661/1673 37s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/zgevjw988vkf.o
[1662/1673 16s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/fslseevlmxb4.o
[1663/1673 28s] C_Android_arm64 Library/Bee/artifacts/Android/d8kzr/p7zzlbdkr3o1.o
[1664/1673 1s] Link_Android_arm64 Library/Bee/artifacts/Android/d8kzr/libil2cpp.so
--------------

Hope that helps a bit! Thanks for the assist.

 

I'm using the same version and it takes a lot of time to do 'compiling cpp for libil2cpp'. Hope you can look into this. Thank you in advance!

 

Awesome! That's great, never saw that before.

So I loaded up a build report that took 10mins to complete. It actually shows exactly how I described it before:
The usual process happens in less than a minute, then spends the rest of the time of something fishy. Then gradle build quickly before ended.

I've attached screenshots of the report, can see the majority of time is spent in "UpdateFromStreamAsync", and then inside that there's a huge amount of "ReadAsync". Not entirely sure what any of this means though, so any guidance here would be appreciated.

If your guess is correct though, is there a more stable version of Android NDK I should be using if not the one that comes with Unity?

Thanks!

 

Sharing this part of the log as well. As this seems to be what we see as well in the build log. The " C_Android_arm64 " which I meantioned previous seems to be hogging up all the power for 10mins.

Though based onlooking at the log, and the loading bar together I can see there seems to be some kind of repetition somewhere that's causing this? For example, when I make bigger changes to the project, it'll take 3mins or less to build previously.

Here we can see, it gets through a first phase of compiling at about 3mins, which is normal. And would usually finish then with a build time of 3mins. But instead, even the loading bar returns from almost finished back to the start. And starts all over again. But this time round for the next 7 mins throttles my CPU and then finishes the build after that.

This is reflected in the loading bar, the build log and the build report.

It's not like the entire process is just overall longer, it looks like it's trying to do something after it should be complete. Though very occasionally it doesn't. For example, this morning I logged in, pulled changes from git, and the project built in under a minute! Hurrah! But then... I tried to build a second time after a tiny bit of work, and it takes 10mins. And now all builds take 10-20mins, even when I don't do anything.

 

Done! Thanks.

 

What's the issue? @JoshPeterson any updates? thank you