Official IL2CPP Build Time Improvements - Seeking Feedback

Sounds interesting!
I'm wondering a bit why you share detailed graphs about the build times but not about the possible performance regression. We're using a lot of generics so it would certainly be interesting which microbenchmarks show what slowdowns, and also how the above examples do in terms of performance. Mind sharing that?

 

Unfortunately, I don't have any projects to really test the changes on but I just want to add my two cents.
Personally, I'd rather have longer build times for more performance. The Release setting could be close to final and faster with these new changes while Master could take longer but maximizes performance.

 

Presumably this will be a configurable setting. Especially because there is bound to be corner-case code where sharing generics proves to be very slow (like the micro-benchmark mentioned above).

Glad to see this! I would try this out if we were on the Alpha. Looking forward to seeing what other people observe.

 

I observed a shorter build time when trying this out, but I immediately get nullreferenceexception when I run the build (happening when loading an addresable scene). Building with mono works though.

So I have to say that I'd much rather it works than it being fast hehe

Unity 2019.4.21f1

Clean - 

Build completed with a result of 'Succeeded' in 1431 seconds (1431279 ms)

Build completed with a result of 'Succeeded' in 468 seconds (467873 ms)

Build completed with a result of 'Succeeded' in 462 seconds (462387 ms)



Unity 2020.2.6f1

Clean - Build completed with a result of 'Succeeded' in 1052 seconds (1051999 ms)

Build completed with a result of 'Succeeded' in 136 seconds (135982 ms)

Build completed with a result of 'Succeeded' in 135 seconds (134927 ms)



Unity 2021.2.0a6.1011

Clean - Build completed with a result of 'Succeeded' in 681 seconds (681159 ms)

Build completed with a result of 'Succeeded' in 102 seconds (102462 ms)

Build completed with a result of 'Succeeded' in 105 seconds (105499 ms)

 

I gotta say I am impressed by the speed upgrade when going from 2019.4 LTS to 2020.2. Cant wait for 2020 LTS version, its going to be very good!

 

I've just ran some tests and got surprising results, in that building is SLOWER than before!

(Note: All builds are development builds, with ILC2PP configuration "master")

Build Time

Build Size

I was quite careful in testing, making sure to close unity between each build (& after upgrading before making B.) so this is quite weird. I've also made some profiler snapshots for each build, I'll send you a DM with those & some extra details (like the profile.json) later today.

 

Hey Jon, thanks for clarifying the main use case you're looking for. I think I'll do another test later today and otherwise next week. I had killed unity & the hub, so its strange that "C" didn't pickup the environment variable... will check more closely. (I had assumed it worked because the build time was so much shorter again)

As for building "ReleasePlus", I was already fully aware that its not really intended for iteration, but I was also very curious about the possible performance drop and thus thought I'd use the "optimum" setting for that. Note that I'm also very much of the opinion that unity devs should be able to choose for the maximum runtime performance, especially when developing for slower platforms than PC and trying to hit a stable FPS, 10% extra performance cost for scripting is quite a lot!

In addition, I am indeed using VS2017. This is because some platforms require use of 2017 rather than 2019. Good to know that 2019 is faster though, will keep that in mind!

 

Couldn't help myself, did it right away. This time I used the IL2CPP configuration "release" instead, and also did cold/warm tests. All builds are using Unity 2021.1.0a8

I hope this time the environment variable stuck properly. Stats may be slightly skewed because I restarted my PC between no-env & env builds.

Build Time

I again sent a DM with the other details inside.

 

When trying to Il2CPP build an empty project with 2021.2.0.0a9.1376 i get this error during build time:

Exception: Unity.IL2CPP.Building.BuilderFailedException: Build failed with 190 successful nodes and 1 failed ones

Annotation: C_Win64_VS2019Pch y2vq/pch-cpp-3692469889848082439.pch (+obj)

...

Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt" /I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\cppwinrt" /Fo"y2vq\pch-cpp-3692469889848082439.obj" /D_HAS_AUTO_PTR_ETC=1 /D_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS /D_SILENCE_ALL_CXX20_DEPRECATION_WARNINGS /Zc:__cplusplus /std:c++17

ExitCode: 1

Stdout:

pch-cpp.hpp

c1xx: fatal error C1083: Cannot open source file: 'Files\Unity\Hub\Editor\2021.2.0a9\Editor\Data\il2cpp\libil2cpp\pch\pch-cpp.hpp': No such file or directory

pch-cpp.hpp

c1xx: fatal error C1083: Cannot open source file: 'Files\Unity\Hub\Editor\2021.2.0a9\Editor\Data\il2cpp\libil2cpp\pch\pch-cpp.hpp': No such file or directory

pch-cpp-3692469889848082439.cpp

C:\Users\User\Desktop\tessddd\New Unity Project\Library\il2cpp_cache\buildstate\y2vq\pch-cpp-3692469889848082439.cpp: fatal error C1083: Cannot open include file: 'C:\Program': No such file or directory

It seems that pch-cpp.hpp is missing although it is on my computer.

Any idea ? I really wish i could try the 2021.2 new features.

 

@joncham yup it seems due to the space of "Program Files", thank you !

 

@joncham, would these improvement also work when building for WebGL or is it limited to mobile/desktop toolchains?

Thanks

 

I've noticed faster builds lately (I generally update to the latest alpha when I notice it, or soon thereafter). Actually there have even been times I was like did it really finish already? For WebGL that's a pretty big deal So yeah.. whatever you're doing, thanks.

 

@joncham A very long moment is spent waiting for the Microsoft Incremental Linker. I noticed that this process is single thread. On console, we are wasting a considerable amount of time because of this. Would it be possible to analyze if you could use all available CPU cores? Thank you!

 

So I was mainly interested in checking out these possible performance implications of this option: "We want to know if you see real world performance issues when running with this option"

Especially the example provided above regarding equality comparision and GetHashCode being much slower piqued my interest.
We have a pretty sophisticated save/load system at the heart of our game where we use and abuse Dictionaries a lot, so GetHashCode gets called quite often on various objects all over the place.

Sadly i couldn't even get as far as testing save performance, since the game just straight out crashes during saving when running with full generic sharing enabled.

I didn't check build time differences or FPS yet, as I'm mainly interested in the saving and loading impact. Is there anything I could share regarding this issue that would be helpful to you to fix this? Sharing the project sadly is no option since it is way too big.

For now i've attached the profile.json files for both a regular il2cpp build and one with the new option enabled.

(Tested with Unity 2021.2.0a12)


Stack trace of crash:

Code (CSharp):

1. ========== OUTPUTTING STACK TRACE ==================
2.  
3. 0x00007FF8F1181F20 (GameAssembly) [u:\desperados_unity_2021.2a\_unity_install\editor\data\il2cpp\libil2cpp\codegen\il2cpp-codegen-il2cpp.cpp:890] il2cpp_codegen_runtime_constrained_call
4. 0x00007FF8F2B03208 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\generics6.cpp:13965] ObjectEqualityComparer_1_GetHashCode_m04F4321254D5C4DB954043E12F6B360683A3FE83_gshared
5. 0x00007FF8F10C42F1 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\il2cppinvokertable.cpp:40369] RuntimeInvoker_TrueInt32_t680FF22E76F6EFAD4375103CBBFFA0421349384C_Il2CppFullySharedGenericAny
6. 0x00007FF8F17EB60B (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp16.cpp:20356] MiCharacterNPCWeaponHolder_GetHashCode_m217FB843B629933D7B6D64C7C67CA7B8EC3FF25C
7. 0x00007FF8F107445C (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\il2cppinvokertable.cpp:44473] RuntimeInvoker_TrueInt32_t680FF22E76F6EFAD4375103CBBFFA0421349384C
8. 0x00007FF8F1181F26 (GameAssembly) [u:\desperados_unity_2021.2a\_unity_install\editor\data\il2cpp\libil2cpp\codegen\il2cpp-codegen-il2cpp.cpp:890] il2cpp_codegen_runtime_constrained_call
9. 0x00007FF8F2B03208 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\generics6.cpp:13965] ObjectEqualityComparer_1_GetHashCode_m04F4321254D5C4DB954043E12F6B360683A3FE83_gshared
10. 0x00007FF8F10C42F1 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\il2cppinvokertable.cpp:40369] RuntimeInvoker_TrueInt32_t680FF22E76F6EFAD4375103CBBFFA0421349384C_Il2CppFullySharedGenericAny
11. 0x00007FF8F0FE56A7 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp-firstpass12.cpp:249] InterfaceFuncInvoker1<int,Il2CppObject *>::Invoke
12. 0x00007FF8F2A76737 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\generics3.cpp:20746] Dictionary_2_FindEntry_mC9A39BDAA66FDC3D9E96031E0EB4D71E51306E46_gshared
13. 0x00007FF8F10C42F1 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\il2cppinvokertable.cpp:40369] RuntimeInvoker_TrueInt32_t680FF22E76F6EFAD4375103CBBFFA0421349384C_Il2CppFullySharedGenericAny
14. 0x00007FF8F2A7ACDE (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\generics3.cpp:21710] Dictionary_2_TryGetValue_mC15984CACD8C4EC727085E5BA025AF6CA0D158DB_gshared
15. 0x00007FF8F14EC397 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp-firstpass6.cpp:24401] SaveLoadSceneManager_iRefToID_mEFC75EA9734E2A7C9B9B2349BA1E91674EAD7FE2
16. 0x00007FF8F14E1690 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp-firstpass6.cpp:21709] SaveLoadSceneManager_castToYamlSerializable_m842964935ECCCE167A2B89B0D41878866DD0B0BC
17. 0x00007FF8F14EDFBB (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp-firstpass6.cpp:20443] SaveLoadSceneManager_reflectMiSerializeInfo_mB54930FF38D3506C72FFCFC27DE816CFA2DF1E4F
18. 0x00007FF8F14EBB4E (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp-firstpass6.cpp:17684] SaveLoadSceneManager_handleSerializeInfosForClass_m1BCDFE87EA546F5BAD2FF76355441557E898DF52
19. 0x00007FF8F14E7E49 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp-firstpass6.cpp:16509] SaveLoadSceneManager_createValueTypeData_m2AF9AA486E67C808AC63707C7C91E6254F5701BA
20. 0x00007FF8F1A9F126 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\assembly-csharp42.cpp:26105] U3CcreateSceneSaveDateAndStoreToMemberU3Ed__85_MoveNext_m8FDC2EDE5F0307820A57F531E1CC45367F15B2B0
21. 0x00007FF8F107E98C (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\il2cppinvokertable.cpp:45097] RuntimeInvoker_TrueSByte_tFEFFEF5D2FEBF5207950AE6FAC150FC53B668DB5
22. 0x00007FF8F389C243 (GameAssembly) [u:\desperados_unity_2021.2a\library\il2cppbuildcache\windows\x64\il2cppoutput\unityengine.coremodule1.cpp:19961] SetupCoroutine_InvokeMoveNext_m4C8B79D8A35F69EEECAA16C82793525E74D75CE9
23. 0x00007FF8F11E3126 (GameAssembly) [u:\desperados_unity_2021.2a\_unity_install\editor\data\il2cpp\libil2cpp\vm\runtime.cpp:583] il2cpp::vm::Runtime::InvokeWithThrow
24. 0x00007FF8F11E2BF1 (GameAssembly) [u:\desperados_unity_2021.2a\_unity_install\editor\data\il2cpp\libil2cpp\vm\runtime.cpp:568] il2cpp::vm::Runtime::Invoke

 

Why is not a setting that would go on projectsettings.asset and under version control? The setting on that window is not stored and it's harder to make CI build because you need a custom script.

 

For each of the options I did a build, closed the editor, re-opened the editor then did the build again, with the times given below based on being the first thing done after a fresh startup of the editor.

Faster runtime:
Build completed with a result of 'Succeeded' in 234 seconds (233790 ms)

Faster (smaller) builds:
Build completed with a result of 'Succeeded' in 19 seconds (19431 ms)

Later after using the editor for a while I also did a 2nd attempt on each one sequentially to confirm the earlier times weren't anomalous, and these came out at 225s and 20s. The WebGL builds both did run and 19s vs. 234s to go from editor to browser is HUGE. However, I couldn't do any kind of performance or framerate comparison. There was an issue with Addressables (1.17.17) for me at runtime which only happened when using the new option (that took 19 s). I switched to development build, full stack trace etc., rebuilt, tried again, here's the error from the javascript console:

Code (JavaScript):

1. NullReferenceException: Object reference not set to an instance of an object.
2.   at UnityEngine.ResourceManagement.ResourceManager.ProvideResourceGroupCached (System.Collections.Generic.IList`1[T] locations, System.Int32 groupHash, System.Type desiredType, System.Action`1[T] callback, System.Boolean releaseDependenciesOnFailure) [0x00000] in <00000000000000000000000000000000>:0
3.   at UnityEngine.ResourceManagement.ResourceManager.ProvideResource (UnityEngine.ResourceManagement.ResourceLocations.IResourceLocation location, System.Type desiredType, System.Boolean releaseDependenciesOnFailure) [0x00000] in <00000000000000000000000000000000>:0
4.   at UnityEngine.ResourceManagement.ResourceManager.ProvideResource[TObject] (UnityEngine.ResourceManagement.ResourceLocations.IResourceLocation location) [0x00000] in <00000000000000000000000000000000>:0
5.   at UnityEngine.AddressableAssets.AddressablesImpl.LoadAssetAsync[TObject] (System.Object key) [0x00000] in <00000000000000000000000000000000>:0
6.   at UnityEngine.AddressableAssets.Addressables.LoadAssetAsync[TObject] (System.Object key) [0x00000] in <00000000000000000000000000000000>:0

..and the above is triggered by a call like .

asyncHandle = Addressables.LoadAssetAsync<UnityEngine.Object>(the_addressable_name);

I don't know if it's just something about how I work with Addressables or there's actually an issue. I'll be sticking with the faster runtime setting at least for now and would for builds being released anyway.

Also, @bdovaz not sure this helps but you can specify the setting via script like this:

Code (CSharp):

1. EditorUserBuildSettings.il2CppCodeGeneration = UnityEditor.Build.Il2CppCodeGeneration.OptimizeSpeed;
2. // or..
3. EditorUserBuildSettings.il2CppCodeGeneration = UnityEditor.Build.Il2CppCodeGeneration.OptimizeSize;

 

Thanks @jukka_j - I guess with nothing changing, my previous times were meaningless . I also have editor scripts that might have invalidated something cached. Also, there's the other "Code Optimization" dropdown that went without attention. So another run at this..

First the baseline - no editor restarting, compiled once and then again for each combination of IL2CPP option and Code Optimization option with no changes to code or assets. Regardless of which combination it took 20-21 seconds.

For Test A, adding or removing private float variables to a MonoBehaviour and something in Awake that changes the values. Repeated 4 times for each of the 4 combinations:
Faster (smaller) builds + Code Optimization for Size: 169s, 170s, 169s, 169s
Faster (smaller) builds + Code Optimization for Speed: 187s, 186s, 199s, 184s
Faster runtime + Code Optimization for Size: 196s, 195s, 194s, 194s
Faster runtime + Code Optimization for Speed: 229s, 215s, 279s, 234s

For Test B, added a 3D Object->Sphere, rebuilt the project. Moved the sphere around and changed properties of the Sphere Collider before each build. Repeated several times and it was always 20-22 seconds, regardless of which setting (sometimes speed took less time, sometimes size). I don't think my Test B results could be considered typical though, because almost no content is actually in my scenes (i.e. I'm loading anything significant into the scene via Addressables and generating a lot of stuff procedurally).

Anyway it's great to see there's effort going into build times and performance - it is definitely appreciated.

 

What about sub optimal files sizes especially for aspects of Unity that generate lots of very small and inefficient files* e.g. .umbracache .bin etc.

Modern HDs SSDs and NVMes hit optimal read and write speeds around the 32-64kb file size.

*NTFS drives with default sectors of 2k+ lose 2x or higher in space for very small files.

 

I was follow up on this thread from https://forum.unity.com/threads/are...tor-allowed-on-ios.489498/page-2#post-7263739

And it seem that this new feature also allow System.Linq.Expressions to use value type under IL2CPP too isn't it? (because there is full generic sharing)

 

@joncham Very interesting stuff, code-size has been quite a problem for our project. At one point we considered writing an in-house roslyn rewriter to improve generics sharing, but we decided against it because of the time investment required.

We'll try update our project to the latest unity beta, to see the results of full generic sharing. In the meantime, would you mind explaining exactly what 'full generic sharing' involves?

- are ALL valuetypes converted to reference types. eg List<int>, List<MyEnum>, List<MyStruct>
- I assume that 'full' generics sharing involves boxing each argument?
- is there a way to customize this behavior for each type/method/all-methods-of-class-or-struct

 

I quickly tested a small sideproject on Windows 10.
The build time improvements are nice. They went down by 50-66%.
The build size improvements are minimal. Only a few megabytes less.
The runtime performance is worse for me. About 3% slower.

Personally I think this is a great feature for faster debugging, but that's about it. Sure, add it, improve it, but please, don't force us to use it.
I don't care if the game is a bit bigger or if final builds take longer. What I care about is runtime performance for my players, and sacrificing even 1% performance for the current advantages is hard to justify in my opionion.

Honestly, to me it looks a bit like you are seeking confirmation here to consider making this the default/only option in the future. And that's exactly why I'm answering now: don't force us to use it. Make it optional.
Maybe it's more work for you to maintain both versions, but please, don't make the experience for the players worse just to save some final build time for the developers. I mean what's the ratio, 1 developer waiting for a build for 1000 players running it? Better wait 2 minutes longer then instead of damaging the experience for your whole playerbase.

 

I'm sure there might be ways to close that performance drop gap anyways, and given that we just hit a new generation of consoles and g-cards making this the default may make sense.

But TBH I would feel better if Unity could commit to closing that gap as much as possible and not throwing the issue on a "not so important" list to look at later.

 

My project fails to build, using faster runtime or faster builds, net standard, Unity 2021.2.0b6:

Code (CSharp):

1. C:\Program Files\Unity\Hub\Editor\2021.2.0b6\Editor\Data\il2cpp\build\deploy\net5.0\il2cpp.exe @Library\Bee\artifacts\rsp\12307732474854830548.rsp
2. Error: IL2CPP error for type 'System.ValueTuple`2' in assembly 'C:\projectpath\Library\Bee\artifacts\WinPlayerBuildProgram\ManagedStripped\mscorlib.dll'
3. System.InvalidOperationException: Attempted to lookup type that hasn't been created
4.   at Unity.IL2CPP.DataModel.BuildLogic.Repositories.ReadonlyMemberStorageStrategy.GetOrAdd[TArg,TKey,TDataModel](Dictionary`2 mapping, TArg arg, TKey elementType, Func`3 create, Action`2 onCreated)
5.   at Unity.IL2CPP.DataModel.Creation.FullyConstructedTypeFactory.CreateFieldReference(TypeReference declaringType, FieldReference fieldReference)
6.   at Unity.IL2CPP.TypeDefinitionWriter.MakeFieldWriteInstructionsForType(SourceWritingContext context, TypeReference type, TypeDefinition typeDefinition, FieldType fieldType)
7.   at Unity.IL2CPP.TypeDefinitionWriter.WriteFieldsWithAccessors(SourceWritingContext context, IGeneratedCodeWriter writer, TypeReference type, Boolean isUnmanagedType, FieldType fieldType)
8.   at Unity.IL2CPP.TypeDefinitionWriter.WriteTypeDefinitionFor(SourceWritingContext context, TypeReference type, IGeneratedCodeWriter writer)
9.   at Unity.IL2CPP.CppDeclarations.CppDeclarationsCollector.BuildCacheData(SourceWritingContext context, TypeReference type, CppDeclarationsCache cache)
10.   at Unity.IL2CPP.CppDeclarations.CppDeclarationsCollector.PopulateCache(SourceWritingContext context, IEnumerable`1 rootTypes, CppDeclarationsCache cache)
11.   at Unity.IL2CPP.CppDeclarations.CppDeclarationsWriter.CollectDeclarations(SourceWritingContext context, ICppDeclarations declarationsIn, CppDeclarations& declarations)
12.   at Unity.IL2CPP.CppDeclarations.CppDeclarationsWriter.Write(SourceWritingContext context, StreamWriter writer, ICppDeclarations declarationsIn)
13.   at Unity.IL2CPP.CodeWriters.GeneratedCodeSourceCodeWriter.Dispose()
14.   at Unity.IL2CPP.TableWriters.ScheduledTableWriterBaseChunkedTransform`3.PostProcessWorker(WorkItemData`3 data)
15.   at Unity.IL2CPP.Contexts.Scheduling.PhaseWorkScheduler`1.WorkerLoop(Object data)
16. UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)

 

Just a few quick tests:

WebGL delivery platform

Build sizes
2020.3.0f1 (speed)
build/ = 31.4mb
webGL/ = 65.2mb (addressables)

2021.1.16f1 (speed)
identical to 2020.3.0f1

2021.2.0b6.3225 (faster (smaller) builds)
build/ = 31.9mb
webGL/ = 66.9mb (addressables)

2021.2.0b6.3225 (faster runtime)
build/ = 32.5mb
webGL/ = 66.9mb (addressables)

Build times
~350-400+ secs (lts and tech versions)
348 secs (faster (smaller) builds)
168 secs (faster (smaller) builds after minor script change)
246 secs (faster runtime)

Performance impact
'faster (smaller) builds' hangs when trying to load scene, also get MethodAccessException errors on start
'faster runtime' loads and runs fine

Preference
Faster runtime, 0.6mb build size negligible, build time still shows improvement, project runs

 

Hi, case 1356746. It was a bit difficult to find the cause but I got il2cpp.exe debugging working using dotPeek.

After changes I had a different build bug with static field in interface: Case 1356753 (https://issuetracker.unity3d.com/is...g-an-interface-with-static-fields-in-a-script)

After moving it to static class project finally builds and runs but it has some runtime errors when using one dll that does a lot of marshaling. I'll report more in a month as mono is fine for development currently.

 

While making a bug report for another game with il2cpp runtime crash in 2020.3 I've tried to build it on 2021.2.0b7. As you can guess it didn't work. Case 1357806.

It looks scary:

Code (CSharp):

1. Building Library\Bee\artifacts\WinPlayerBuildProgram\ql6z\tjek_ILRuntime2.obj failed with output:
2. ILRuntime2.cpp
3. C:\Program Files\Unity\Hub\Editor\2021.2.0b7\Editor\Data\il2cpp\libil2cpp\codegen\il2cpp-codegen-il2cpp.h(411): error C2296: '&': illegal, left operand has type 'T'
4.         with
5.         [
6.             T=Enum_t2A1A94B24E3B776EEF4E5E485E290BB9D4D072E2 *
7.         ]
8. \Library\Bee\artifacts\WinPlayerBuildProgram\il2cppOutput\cpp\ILRuntime2.cpp(19938): note: see reference to function template instantiation 'bool il2cpp_codegen_enum_has_flag<Enum_t2A1A94B24E3B776EEF4E5E485E290BB9D4D072E2*>(T,T)' being compiled
9.         with
10.         [
11.             T=Enum_t2A1A94B24E3B776EEF4E5E485E290BB9D4D072E2 *
12.         ]
13. C:\Program Files\Unity\Hub\Editor\2021.2.0b7\Editor\Data\il2cpp\libil2cpp\codegen\il2cpp-codegen-il2cpp.h(411): error C2297: '&': illegal, right operand has type 'T'
14.         with
15.         [
16.             T=Enum_t2A1A94B24E3B776EEF4E5E485E290BB9D4D072E2 *
17.         ]

 

Nintendo Switch is the fastest IL2CPP target to build for (by a huge margin) in my experience. Can't get into details due to NDA stuff, but it seems to use some form of caching I haven't seen in any other IL2CPP target, which greatly speeds up compiling and linking. Not sure why these aren't used on other targets.

 

I

It creates additional files and directories unlike the other targets which also use Clang for compiling, and seems to use that for fast incremental linking.

Linking is by far the longest part of building with IL2CPP in my experience with other platforms. Linking is also a mostly single threaded task: while I can blaze through the compilation by throwing a 32 core CPU at it, there's no bribing linking into going faster.

Anyway, it's worth tracking down whatever team was behind the Switch building process and check how they did it, and if it can be leveraged for other platforms (or at the very least other Clang-based platforms like Android.)

 

Found another one:

(Case 1361232) IL2CPP player crash regression

Mono works fine and 2020.3 il2cpp also.

 

Is there any chance this will be backported into 2020.3 LTS? IL2CPP build is the bottleneck in our CI pipeline.

 

It seems less stable than the older code generation option. I compiled my scene in faster-build, but the player for it ends up crashing whenever started. I compiled it again with faster-runtime and it works as expected.
Although I was using the HDRP with latest 2022 alpha and SRP github master.

I ended up sending a bug report but only with the scene as a package(project 2 big), and it's a bit different compared to mine but maybe it'll still lead to a crash.

Case 1365032

 

Finally got around to trying it out properly. However we ran into this issue https://fogbugz.unity3d.com/default.asp?1366578