Question

Normally, I’d never have to ask myself whether a given scenario is better suited to a struct or class and frankly I did not ask that question before going the class way in this case. Now that I’m optimizing, things are getting a little confusing.

I’m writing a number crunching application that deals with extremely large numbers containing millions of Base10 digits. The numbers are (x,y) coordinates in 2D space. The main algorithm is pretty sequential and has no more than 200 instances of the class Cell (listed below) in memory at any given time. Each instance of the class takes up approximately 5MB of memory resulting in no more than 1GB in total peak memory for the application. The finished product will run on a 16 core machine with 20GB of RAM and no other applications hogging up the resources.

Here is the class:

// Inheritance is convenient but not absolutely necessary here.
public sealed class Cell: CellBase
{
    // Will contain numbers with millions of digits (512KB on average).
    public System.Numerics.BigInteger X = 0;
    // Will contain numbers with millions of digits (512KB on average).
    public System.Numerics.BigInteger Y = 0;

    public double XLogD = 0D;
    // Size of the array is roughly Base2Log(this.X).
    public byte [] XBytes = null;

    public double YLogD = 0D;
    // Size of the array is roughly Base2Log(this.Y).
    public byte [] YBytes = null;

    // Tons of other properties for scientific calculations on X and Y.
    // NOTE: 90% of the other fields and properties are structs (similar to BigInteger).

    public Cell (System.Numerics.BigInteger x, System.Numerics.BigInteger y)
    {
        this.X = x;
        this.XLogD = System.Numerics.BigInteger.Log(x, 2);
        this.XBytes = x.ToByteArray();

        this.Y = y;
        this.YLogD = System.Numerics.BigInteger.Log(y, 2);
        this.YBytes = y.ToByteArray();
    }
}

I chose to use a class instead of a struct simply because it ‘felt’ more natural. The number of fields, methods and memory all instinctively pointed to classes as opposed to structs. I further justified that by considering how much overhead temporary assignment calls would have since the underlying primary objects are instances of BigInteger, which itself is a struct.

The question is, have I chosen wisely here considering speed efficiency is the ultimate goal in this case?

Here’s a bit about the algorithm in case it helps. In each iteration:

1. Sorting performed once on all 200 instances. 20% of execution time.
2. Calculating neighboring (x,y) coordinates of interest. 60% of execution time.
3. Parallel/Threading overhead for point 2 above. 10% of execution time.
4. Branching overhead. 10% of execution time.
5. The most expensive function: BigInteger.ToByteArray() (implementation).

Answer 1

It’s hard to tell based on what you’ve written (we don’t know how often you end up copying a value of type Cell for example) but I would strongly expect a class to be the correct approach here.

The number of methods in the class is irrelevant, but if it has lots of fields you need to consider the impact of copying all those fields any time you pass a value to another method (etc).

Fundamentally it doesn’t feel like a value type to start with – but I understand that if performance is particularly important, the philosophical aspects may not be as interesting to you.

So yes, I think you’ve made the right decision, and I see no reason to believe anything else at the moment – but of course if you can easily change the decision and test it as a struct, that would be better than guesswork. Performance is remarkably difficult to predict accurately.