I'm currently working on performance optimizations for Project 5: Sightseer, and a part of that involved editing the UnityEngine.dll to fix a nasty bug Unity introduced back in ~2014 that they seem to refuse to fix. That bug, is an absurd amount of GC allocations coming from the AttributeHelperEngine.
The bug in question is glaringly obvious to anyone even with a little proficiency in C#, and stems from the lack of caching of expensive GetAttributes calls:
https://github.com/MattRix/UnityDecompiled/blob/master/UnityEngine/UnityEngine/AttributeHelperEngine.csAmusingly, the bug has been reported to Unity years ago, alongside the code required to fix it (
https://fogbugz.unity3d.com/default.asp?746364_pjnmdhk7c9imgdsk)... and yet -- Unity refused to do anything about it, claiming that a future redesign of the system will fix it. Well, guys -- fast forward to several years later -- the bug is still there, all the way in Unity 2017.2, and no actions have been taken to address it.
Here's the thing about closing bugs that are affecting people
today hoping for a future redesign to fix it
later -- until this "later" comes, the problem will still keep affecting all 4.5 million Unity developers, and it can be (and usually is) years before gets resolved! And if someone submits a bug report with actual code on how to fix it -- why not fix it? Boggles my mind...
Anyway -- this post isn't meant to be a rant about Unity's choices -- I'll do that in another one. Instead, let me explain how you -- the developer -- can fix this problem yourself, to an extent. Fortunately, this particular problem comes from the side of Unity that lives in the UnityEngine.dll file, and C# files are quite easy to modify. The first thing we need to do is make a new C# project in Visual Studio.
I was editing Unity 5.6.4f1 -- so I made the application target .NET Framework 3.5. "The Output type" needs to be a Class Library -- as we need to create a DLL with the edited functions first.
Compile this code into a DLL:
using System;
namespace UnityEngine
{
internal class AttributeHelperEngine
{
private static Type GetParentTypeDisallowingMultipleInclusion (Type type)
{
return null;
}
private static Type[] GetRequiredComponents (Type klass)
{
return null;
}
}
}
This simple DLL will not be referencing any Unity classes, so there is no need to reference the UnityEngine.dll. Compile the DLL (I targeted Release) and move it into the solution folder, or somewhere you can find it. I called mine FixUnityEngine.dll. If you choose to fix it by adding caching instead, like in the bug report's suggested fix code, you will need to reference the UnityEngine.dll. Personally, I saw no adverse effects of simply returning 'null' in Sightseer. Worked just fine.
The next step is to create a program that will replace the code in one DLL (UnityEngine.dll) with code from another (FixUnityEngine.dll). Since I no longer needed the code above, I simply commented it out, choosing to reuse the project instead of making a new one -- but if you plan on editing your replacement code you may want to create a separate VS solution.
The API that lets us devs replace C# code is part of Mono.Cecil, but interestingly enough it's actually a part of the Visual Studio installation, at least in the current version (2017). Here's all the code needed to edit the DLL:
using System;
using Mono.Cecil;
public class Application
{
static MethodDefinition Extract (AssemblyDefinition asm, string type, string func)
{
var mod = asm.MainModule;
if (mod == null) return null;
var existingType = mod.GetType(type);
if (existingType == null) return null;
var methods = existingType.Methods;
foreach (var method in methods)
{
if (method.Name == func)
{
return method;
}
}
return null;
}
static bool Replace (AssemblyDefinition original, AssemblyDefinition replacement, string type, string func)
{
var method0 = Extract(original, type, func);
var method1 = Extract(replacement, type, func);
if (method0 != null && method1 != null)
{
method0.Body = method1.Body;
Console.WriteLine("Replaced " + type + "." + func);
return true;
}
Console.WriteLine("Unable to replace " + type + "." + func);
return false;
}
static int Main (string[] args)
{
var dll0 = "C:/Projects/FixUnityEngine/UnityEngine.dll";
var dll1 = "C:/Projects/FixUnityEngine/FixUnityEngine.dll";
var asm0 = AssemblyDefinition.ReadAssembly(dll0);
var asm1 = AssemblyDefinition.ReadAssembly(dll1);
Replace(asm0, asm1, "UnityEngine.AttributeHelperEngine", "GetParentTypeDisallowingMultipleInclusion");
Replace(asm0, asm1, "UnityEngine.AttributeHelperEngine", "GetRequiredComponents");
asm0.Write("C:/Projects/FixUnityEngine/UnityEngine_edited.dll");
Console.ReadKey();
return 0;
}
}
You may notice that I'm referencing a local copy of UnityEngine.dll -- I chose to copy it to the project's folder, but you can reference it all the way in Program Files if you like. Its default location is "C:\Program Files\Unity\Editor\Data\Managed\UnityEngine.dll".
So what does the code do? It simply reads the two DLLs and replaces the body of one function with another! In the replacement DLL I kept the same namespace, class name and function names for consistency (but as far as I can tell this isn't actually necessary). In my case though, since I did, the code to perform the replacement ended up being shorter.
Once you compile and run the program, it will spit out an edited version of the DLL (UnityEngine_edited.dll). Simply close all instances of Unity and replace C:\Program Files\Unity\Editor\Data\Managed\UnityEngine.dll with this version. That's it.
Want to test the result? Here's a test program for you:
using UnityEngine;
public class Test : MonoBehaviour
{
private void Update ()
{
var go = gameObject;
if (Input.GetKeyDown(KeyCode.Alpha1))
{
for (int i = 0; i < 1000; ++i)
{
var t2 = go.AddComponent<Test2>();
Destroy(t2);
}
}
}
}
using UnityEngine;
public class Test2 : MonoBehaviour {}
The actual GC amounts and timings will vary greatly with project complexity (the more C# scripts you have, the slower the whole process becomes thanks to Unity), but this is what I was seeing before the edit and after:
There's nothing I can do about Unity calling this useless functions, and indeed in my project Unity doing so wastes 0.16 ms per call to AddComponent... but at least the 325 MB of memory allocation is gone. Yay for small victories.
