Question

I’m writing HFT trading software. I’m trying to optimize it. I figured out that every second I create several thousands of Instrument object, the source code of this class below:

public class Instrument
{

    public int GateId { get; set; }
    public string Ticker { get; set; }
    public override string ToString()
    {
        return "GateID: " + GateId + " Ticker: " + Ticker + '.';
    }

    public override bool Equals(object obj)
    {
        if (obj == null)
        {
            return false;
        }
        Instrument instrument = obj as Instrument;
        if (instrument == null)
        {
            return false;
        }
        return (GateId.Equals(instrument.GateId)) && (Ticker.Equals(instrument.Ticker));
    }

    public override int GetHashCode()
    {
        int hash = 13;
        hash = (hash * 7) + GateId;
        hash = (hash * 7) + Ticker.GetHashCode();
        return hash;
    }
}

Actual number of Instruments is pretty limited. It’s about 100 totally. But I constantly create the same Instrument object many times per second, like that:

new Instrument { GateId = 0, Ticker = "MSFT" }

I.e. I have many instances of “MSFT” Instrument but I can use them in HashSet/HashMap or whereever thanks to overriden Equals and GetHashCode methods.

But now I think if it makes sense to have at runtime 10 or 100 “MSFT” Instrument object (that are equals to each other).

So I want to create something like that:

interface InstrumentFactory {

    public Instrument GetInstrument(int GateId, string Ticker);

}

Every time I need some instrument I just want to ask InstrumentFactory. InstrumentFactory will store my 100 instruments in HashSet internally and just will return cached copy. Also I now can remove Equals and GetHashCode methods as I have exactly one Instrument for each gateId + ticker pair.

Questions:

• with new approach will I have noticable perfomance improvements?
• what do you thing about new design? when I frequently need same objects is it better to use factory instead of creating new object every time with overriden Equals and GetHashCode methods?

Answer 1

You can’t currently cache these, because they’re mutable – the Ticker and GateID have public setters.

I would make it immutable (and seal the class), but potentially retain the Equals and GetHashCode methods. Add a constructor to take the parameters instead of setting them as properties.

At that point, it’s a better class anyway IMO (it’s easier to reason about immutable types) and it’s entirely reasonable to cache the values. Will it make your application noticeably faster? We can’t possibly tell that – but you should be able to, assuming you have performance tests already. It would make sense to do so, at least.

EDIT: Note that you won’t just be able to use a HashSet in your factory. You’ll probably want something like a Dictionary<int, Dictionary<string, Instrument>> – look up the gate from the first dictionary, then then instrument from the gate. If you have a known, fixed number of gates starting at 0, you might even want to use an array. You should also consider creating a Gate type.

Use Dictionary.TryGetValue to check for the presence of a gate or an instrument within the gate, and add then lazily create the gate/instrument and put it in the dictionary if it didn’t exist before.

If you’re using multiple threads with a single factory, you’ll need to either use locking, or if you’re using .NET 4 you could use a ConcurrentDictionary. Of course, that’s assuming you don’t know all the instruments up-front. If you do know everything before you start, it’s really easy – just populate the factory to start with, and throw an exception if you’re asked for an instrument which doesn’t exist.