C# Design – Implications of a Large Partial Class

cdesign

I'm writing a middle layer between vendor code and company business logic. Part of the exercise is to insulate our business logic from vendor's types to make swapping out vendor code easier.

As such, I'm writing a lot of extension methods that do translation to and from. I'm placing these extensions in public static partial classes. For organizational purposes and simply because, for static extension methods, the class it self does not matter(is this a correct assumption btw?)

EDIT:
To be clear I'm creating a lot of different appropriately named source files, that all implemented one partial class

My question is, how much code is too much for a partial class. I could conceive having 100's of methods in a single class(at some point). When does this become a burden for the compiler and CIL layer? Is there really a limit if these partials classes hold no state/memory?

Best Answer

TLDR: A single class with hundreds of methods is just fine, you won't get into problems unless you have thousands of methods.

To test this properly, I have created the following T4 template in Visual Studio:

class LotsOfMethods
{
    <# for (int i = 0; i < 100; i++) { #>
    public static void M<#= i #>()
    {
    }
    <# } #>
}

By varying the constant in the loop, I can find out how do various numbers of methods behave. As it turns out, 100, 1 000, 10 000 or even 100 000 methods compile just fine (though in the latter cases, the compilation takes longer than a single project with one or two classes normally would and VS also sometimes freezes for few seconds).

When I tried to actually run the code, the cases with 100, 1 000 or 10 000 methods were all fine. The interesting part is that when you try to use the class with 100 000 methods, you'll get an exception:

System.TypeLoadException: Type 'LotsOfMethods' from assembly 'ConsoleApplication1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' contains more methods than the current implementation allows.

Specifically, this exception happens when the class has 65 521 (216-15) methods or more. (An interesting question is why exactly this number. What does the 15 mean?)

Another observation is that more methods in a class make JIT compilation slower. (Or is it more methods in an assembly? I haven't tested that.) When executing 500 of the methods I get the following results:

For a class with 65 520 methods:

For the first time: 2,2079481 s
For the second time: 0,0003259 s

With 1 000 methods:

For the first time: 0,0545898 s
For the second time: 0,0003138 s

And 500 methods:

For the first time: 0,0361426 s
For the second time: 0,0003226 s

The results were measured using the following code:

var sw = Stopwatch.StartNew();

int n = 500; // this is constant no matter how many methods does the class have

for (int i = 0; i < n; i++)
{
    typeof(LotsOfMethods).GetMethod(string.Format("M{0}", i)).Invoke(null, null);
}

var first = sw.Elapsed.TotalSeconds;
sw.Restart();

for (int i = 0; i < n; i++)
{
    typeof(LotsOfMethods).GetMethod(string.Format("M{0}", i)).Invoke(null, null);
}

var second = sw.Elapsed.TotalSeconds;

Console.WriteLine("For the first time: {0} s", first);
Console.WriteLine("For the second time: {0} s", second);
Related Topic