For the love of god, stop giving methods dozens of parameters

Issue #10262 wontfix
John Snail created an issue

A bunch of methods have ungodly amounts of parameters, all of which get pushed to the stack. Some examples:

GameObjectFactory.CreateObject: 11 instructions. It’s important to note that this adds up from the sheer amount of times this gets called, and the overloads double this count simply from having to pass the parameters over.

Physics.ApplyDischarge: 25 instructions. It calls itself recursively as well. The overloads double this count simply from having to pass the parameters over (also one unused overload just calls itself and causes a stack overflow??). Not sure if this is also used just to transfer electricity, could explain #10091.

BodyPart.AddPartAt: I dunno, like 100 instructions?? The first call alone takes 50 since each Nullable takes 3 (use int.MinValue or something). Then these get passed to AddPart. AddPart or something similar is presumably called when creating objects with bodies, so that’s hundreds of needless instructions per object.

I beg you, use structs or something. I’m not sure if they take less instructions to initialize, but they’ll certainly save instructions on overloads as only one variable gets passed over. Anything is better than this.

IL decompilation of an AddPartAt call:

IL_001a: ldstr "Pseudopod"
IL_001f: ldc.i4.2
IL_0020: ldnull
IL_0021: ldnull
IL_0022: ldnull
IL_0023: ldnull
IL_0024: ldarg.0
IL_0025: call instance string XRL.World.Parts.SoupSludge::get_ManagerID()
IL_002a: ldloca.s 1
IL_002c: initobj valuetype [mscorlib]System.Nullable`1<int32>
IL_0032: ldloc.1
IL_0033: ldloca.s 1
IL_0035: initobj valuetype [mscorlib]System.Nullable`1<int32>
IL_003b: ldloc.1
IL_003c: ldloca.s 1
IL_003e: initobj valuetype [mscorlib]System.Nullable`1<int32>
IL_0044: ldloc.1
IL_0045: ldloca.s 2
IL_0047: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_004d: ldloc.2
IL_004e: ldloca.s 2
IL_0050: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_0056: ldloc.2
IL_0057: ldloca.s 2
IL_0059: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_005f: ldloc.2
IL_0060: ldloca.s 2
IL_0062: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_0068: ldloc.2
IL_0069: ldloca.s 2
IL_006b: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_0071: ldloc.2
IL_0072: ldloca.s 2
IL_0074: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_007a: ldloc.2
IL_007b: ldloca.s 2
IL_007d: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_0083: ldloc.2
IL_0084: ldloca.s 2
IL_0086: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_008c: ldloc.2
IL_008d: ldloca.s 2
IL_008f: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_0095: ldloc.2
IL_0096: ldloca.s 2
IL_0098: initobj valuetype [mscorlib]System.Nullable`1<bool>
IL_009e: ldloc.2
IL_009f: ldstr "Hand"
IL_00a4: ldstr "Missile Weapon"
IL_00a9: ldc.i4.1

Comments (1)

  1. Brian Bucklew repo owner

    This was meaningful in 1985 but not practically meaningful today compared to just blowing the branch prediction (which we do a lot more haha)

  2. Log in to comment