Limit generation of IL2CPP CCWs and GenericComDefinitions?

We have a moderately-sized project that we build for Windows Standalone (Mono) as well as HoloLens (UWP IL2CPP) and I have noticed that the latter generates lots of files (around 600) with the name `Il2CppGenericComDefinitionsXXX.cpp`, most of which contain this:

Code (CSharp):

1. #include "pch-cpp.hpp"
2.  
3. #ifndef _MSC_VER
4. # include <alloca.h>
5. #else
6. # include <malloc.h>
7. #endif
8.  
9.  
10. IL2CPP_EXTERN_C_BEGIN
11. IL2CPP_EXTERN_C_END
12.  

In one of the files which actually contains something it looks like it's instantiations of generic WinRT types, like `IAsyncOperation<SomeType>`. There's around 5 of them, the rest looks like the code block above.
Is it possible to reduce the number of these generated files somehow?

The other kind of generated file is `Il2CppCCWsXXX.cpp`.
These actually all contain code and the name says it's COM callable wrappers, but what exactly are they for? To interop with WinRT collection types internally, maybe (like IVector<T>)?

Is it possible to limit the amount of generated CCWs somehow? I'm not 100% sure if we need so many of them, the UWP-specific code is small in volume compared to the size of the project itself. Also, CCWs are consistently showing up in the top 10 files taking the longest time to build.

Any help/explanations would be appreciated. I haven't found any docs concerning the generation of those files, and the names suggest they're Windows-specific. Unfortunately that's the only platform we support right now, so I can't check if e.g. Android would generate a similar amount of them (or any at all).

 

Very interesting, thank you for the response.

I'll try to repro the empty files thing with a smaller project and report back if there's something.

I do wonder though, would it help if there was a way to say "this assembly does not reference WinRT at all"?
Then again, for public types of that assembly at least, you'd probably still have to generate CCWs since some other assembly that does use WinRT might stick something into a dictionary and pass that into a WinRT object method...

 

Right now, if an assembly does not call WinRT in any way, are CCWs generated for it still? Does reference rewriter always add .winmd references when building for UWP?

 

Also, I've reported the empty Il2CppGenericComDefinitionsXXX files bug with a sample project that contains MRTK.
It's number 1429416.

 

Sorry, I got a bit confused; I meant a setup like this:

- AssemblyThatUsesDictionariesButNoWinRT.dll
- AssemblyThatUsesWinRT.dll

and there is no reference between those two. In theory there should be no CCWs for the 1st assembly's public types, assuming it doesn't use WinRT itself internally?

 

I see, so it's also transitive dependencies/references and passing around objects/IInspectable... :/

Realistically, is there anything we can do to improve codegen/build times aside from being cautious about not to overuse generics and WinRT APIs maybe?
I read that 2021 LTS improves build times a bit, so might get a speedup there, but we're not quite ready to migrate yet.

Also, thank you for the detailed explanations so far.

 

I've already excluded my project directory from defender, so it should not slow down the process.

I just ran a build into a fresh directory, timings are:

1:30 from Unity (with fully cached shaders), without script debugging
3:10 compiling/linking IL2CPP binary (Release mode)
then maybe another minute to actually deploy to HoloLens, but that's Microsoft's tools then.

With managed debugger support it takes longer than that because there's more code being generated. Do you need those numbers as well?

So it's like 5 minutes from code change to actually testing it on device, and I got a pretty beefy machine to begin with (Core i9-12900K, 64GB RAM). Building on a high-end laptop from 2020/2021 can take 8-10 minutes.
Later there's also incremental builds, those don't take as much, but like still around a minute or 2 depending on how big the change is and how many files are regenerated by IL2CPP.

 

Just tried ExecutableOnly build, but it fails with:

Exception: Unity.IL2CPP.Building.BuilderFailedException: schemaClass.cpp
C:\ARES\Library\Il2cppBuildCache\UWP\VSProject\il2cppOutput\schemaClass.cpp(24): fatal error C1083: Cannot open include file: '{{ libraryPath }}/{{ cls.GetHeaderFile() }}': No such file or directory

Anyway, it compiles the same amount of code and in the end has to link against a UWP app stub, right? I don't think it'd be much different timing-wise, except for not having to open VS to build, which can be nice.

About link.xml files:
There's a bunch of them in the project. Some 3rd party dependencies have their own (MRTK, Photon, Zenject, Odin). Also, for some reason the AWS S3 SDK is also set to preserve in one of our own link.xml files which looks unnecessary to me.
I guess if we could trim some of those, we'd get a better build time.

Also, stripping level is set to low. Maybe I could try going with medium and see if it improves things.

 

I have deleted some stuff from link.xml and the results are:

1:22 from Unity (with fully cached shaders), without script debugging
Total compilation time: 129424 milliseconds.
Total link time: 29596 milliseconds.
ObjectFiles: 1987 of which compiled: 1987 (previously around 2050 object files)

So it's 2:40 building from VS, already an improvement. I hope I didn't break anything in the process, but smoke test didn't show anything. Stripping level is still low.

Here's some of the stats that the build process gives me:
1> Time Compile: 128868 milliseconds Il2CppCCWs27.cpp
1> Time Compile: 127900 milliseconds Il2CppCCWs345.cpp
1> Time Compile: 104105 milliseconds Il2CppCCWs177.cpp
1> Time Compile: 24676 milliseconds Generics70.cpp
1> Time Compile: 17976 milliseconds HoloLight.GeneralImportService.Runtime2.cpp
1> Time Compile: 17925 milliseconds Il2CppInvokerTable.cpp
1> Time Compile: 17585 milliseconds Il2CppPCCWMethods.cpp
1> Time Compile: 16773 milliseconds Il2CppCCWs409.cpp
1> Time Compile: 13957 milliseconds Il2CppCCWs412.cpp
1> Time Compile: 12632 milliseconds Generics29.cpp

I think the biggest offender is our "main" assembly which has lots of unnecessary stuff inside and generates 18 .cpp files.
Also, there's 32 GenericMethods and 144 Generics .cpp files generated; there's too many generics crimes in the codebase. I want to reduce those, but it's going to take some time.
It's probably going to reduce the amount of CCWs that have to be generated.

 

It's from the USD package as far as I can see. Not quite sure what it does though, haven't encountered it before.
I know that USD has a post-build step, might be related to that.
Found it here: https://github.com/Unity-Technologi.../usd/resources/codegenTemplates/schemaClass.h

Not sure if this is the exact version because we have a fork of that package that adds HoloLens support (which was made by an external company and not updated ever since), but it used to exist upstream at some point.

 

I'm not sure if the HoloLens support is at fault here, but those files are gone in newer USD package versions.

However, due to it being a fork etc. we'd have to look at upgrading/possibly upstreaming and this almost certainly won't happen right away, so ExecutableOnly is not an option ATM, sadly. :/

Those files do exist for x64 builds too, but we use Mono for desktop, so didn't run into it there.

 

So the respose I got on my bug report is that it's been fixed in 2021.2.
Is it possible to backport this to 2020 LTS? We are not yet ready to migrate to 2021 and might not be able to do that until sometime next year.