Approval to make some optimisations?
Posted: Tue Jul 05, 2022 11:08 pm
I've noticed a few small optimisations that can be made to the engine, and I wanted to see if I can get approval to make these changes before I do so.
The first change is an optimisation to null checks against Unity Objects. The details of this issue can be found here. The gist of it is that when a Unity Object is compared against Null and it is not Null in C# land, the interpreter then makes a call to native code to check if the Object has been disposed in C++ land. This native code call is expensive, but I've worked out an optimisation that can be made which avoids this call. A benchmark I've tested gave me a 33% performance improvement.
Part of the optimisation I want to make involves adding additional arguments to certain public methods, which would obviously break any mods that call them. If I'm not allowed to edit these methods, I can still do the optimisations that don't involve touching these methods. The improvement just won't be as much.
The list of methods I currently want to add additional arguments to are the following:
The second change I want to make is to reduce the number of heap allocations that are currently happening in the codebase, especially when it comes to strings. To do this, I want to add a common StringBuilder to the DaggerfallUnity class. This StringBuilder will then be used by other classes whenever it needs to create a concatenated or formatted string. The result will be that heap allocations will only occur when the final string is created, and if the StringBuilder needs to enlarge it's internal array. Instead of the larger amount of allocations that happen behind the scenes when strings are concatenated or formatted, or when value types are boxed before being turned into a string.
If I can add this common StringBuilder, the next question is whether it should be marked as Internal or Public. Internal means only DFU classes can use it. Public means mods can also use it, but the mod author should be careful to call stringBuilder.Clear() before the method it is used in returns.
The first change is an optimisation to null checks against Unity Objects. The details of this issue can be found here. The gist of it is that when a Unity Object is compared against Null and it is not Null in C# land, the interpreter then makes a call to native code to check if the Object has been disposed in C++ land. This native code call is expensive, but I've worked out an optimisation that can be made which avoids this call. A benchmark I've tested gave me a 33% performance improvement.
Part of the optimisation I want to make involves adding additional arguments to certain public methods, which would obviously break any mods that call them. If I'm not allowed to edit these methods, I can still do the optimisations that don't involve touching these methods. The improvement just won't be as much.
The list of methods I currently want to add additional arguments to are the following:
Code: Select all
GameObjectHelper.AlignControllerToGround()
GameObjectHelper.CreateDaggerfallMeshGameObject()
GameObjectHelper.CreateRMBBlockGameObject()
GameObjectHelper.InstantiatePrefab()
MaterialReader.GetMaterial() (both)
MeshReader.GetMesh()
TextureReader.GetTerrainTextureArray()
TextureReader.GetTexture2D()
TextureReader.GetTexture2DAtlas()
If I can add this common StringBuilder, the next question is whether it should be marked as Internal or Public. Internal means only DFU classes can use it. Public means mods can also use it, but the mod author should be careful to call stringBuilder.Clear() before the method it is used in returns.