[infamousclyde]

Fascinating application of the language and a terrific write-up. I would presume a GC language would normally be a disqualifying factor in real-time trading, but I think I'm coughing up some premature optimization, especially with what looks like a pretty beefy rig. Congratulations though, this is spectacular.

[chollida1]

Nah, if you are retail and using Interactive brokers then you'll never notice teh GC pause at all.

Mostly because you'll never be able to respond to each tick as by the time the tick gets to you the market has moved.

Use the language that you know and can work with the fastest. For retail trading GC vs non GC will never matter at all.

[_zkyx]

Yeah, I never really looked a GC. Most of my trades take at least 500ms+ round trip. It's more in the latency to the broker and getting confirmations that I've been trying to tighten up. At least that's what I'm seeing right now.

[mhh__]

You say this as if memory allocation in general isn't extremely slow.

[kasey_junk]

For trading systems that are still software based they absolutely do not allocate or reclaim on the hot path for this reason.

[infamousclyde]

"That are still software based" is interesting. Are there hardware-based trading systems?

[kasey_junk]

Yes. The fastest systems are asic or fpga based. They typically never leave the router.

[infamousclyde]

I guess my presumption was that algorithmic trading was a very tight feedback loop, with as many controlled variables (i.e., GC) as possible, so I think it just subverted some of my misplaced expectations.