Question

Are there any tangible performance penalties for having a large number of variables, properties, and/or methods in a single C# class?

I have several classes (a chess board, move generator, and a PGN parser) that total about 1,200 lines of code. Both the move generator and the parser are very tightly coupled to the board class, and there is a strong temptation to simply combine all three classes into a single large “kitchen sink” class.

I understand and applaud the concept of keeping each class focused on a single task and cleanly encapsulating their internal design, but since using .NET is a non-negotiable requirement, I’m also willing to sacrifice “purity of design” in return for performance

Other than the obvious issues of readability/maintainability, what are the downsides to having a smaller number of large complex classes, as opposed to a larger number of smaller simple classes?

Cheers!
Humble Programmer
,,,^..^,,,

Answer 1

Are there any tangible performance penalties for having a large number of variables, properties, and/or methods in a single C# class?

Having more variables causes instances to have higher memory usage and potentially longer construction times – this can have a penalty if the variables aren’t necessarily needed in every circumstance.

That being said, the main disadvantages are more in terms of reliability, maintainability, testability.

I understand and applaud the concept of keeping each class focused on a single task and cleanly encapsulating their internal design, but since using .NET is a non-negotiable requirement, I’m also willing to sacrifice “purity of design” in return for performance

.NET has nothing to do with making horrible code – you can have good design and .NET in the same project, and this is, in fact, quite simple to accomplish.

I have several classes (a chess board, move generator, and a PGN parser) that total about 1,200 lines of code. Both the move generator and the parser are very tightly coupled to the board class, and there is a strong temptation to simply combine all three classes into a single large “kitchen sink” class.

I would consider trying to find the motivation to refactor this and decouple it into more, smaller classes. This is likely to help in every way, including performance (if you find it necessary), as it’s typically simpler to fix a performance problem in a clean, well thought-out design than it is to find or fix a performance issue in a tightly coupled, large codebase. Smaller classes are easier to profile and measure, which in turn allows the real performance problems (if any) to be discovered and corrected much more simply than when working from a large mess of code.