Total support. Whatever you do, make it CLEAN first, think of performance second. Now, dont do obviously stupid things (dynamic method calls of any way come to my mind). But besides that... you need to ahvea ton of complex trade logic to make any difference. I personally do run into significant performance problems in parts of my programming, but they ALL resolve around the user interface and require tricks. Simlpy because things like a time and sales simply do not work showing every trade i nreal time - and make no sense, given a maximum of x (normally 60) screen updates from the screen anyway. Anything not related to the user interface - has no performance issue at all. Clean code will make refactoring the critical aprts more easy at a later stage. A lot more easy. In addition, get some proper profiling. For .NET (no C++ fan here, sorry), ants as well as the visual studio 2010 are pretty good. I used the 2010 profile rto really point some blame to Rithmic at one point in the past (on an item they since then have acknowledged), it even gave me (c++ level) method names where the time was spent. This is terrific information you need - performanec optimization must be base on a proper evaluation with a profiler. Or you are hunting ghosts
And you definitely won't be hanging out at ET. If you have the money to play this game and enter the HFT arms race in arenas such as index arb then you'll have your techie minions worrying about all this whilst you sit on your yacht rubbing cooking fat into a bronzed 21 year old.
You may want to check an interesting analysis of Netscape http://www.joelonsoftware.com/articles/fog0000000069.html
it is actually very avoidable, ESPECIALLY in something as simple as trading applications (which are not inherently extremely complicated). I develop today by the same principles like 15 years ago, interesting enough. Same langauge as 10 years ago, though some iterations later. Most architectural concepts have not really changed at all - even the SOA stuff they throw around nowadays has all been seen in CORBA days... a long time ago The problem with many people is that they jump on todays keywords.... instead of sound principles. That said, trading frameworks are inherently not particularly complex.
To my mind the complexity in building trading frameworks isn't in the coding at all...it's in mapping out the possible operational scenarios and ensuring that you handle them in a robust manner. I have generated quite a few Mb of Visio diagrams now in mapping out these functional flows. I would agree that coding up these scenarios once they identified is actually pretty easy. I have found that I use only a fairly small selection of the tools available to me. Like you, I work in C# and find myself constantly hitting the System.Collections.Generic namespace pretty hard.
Exactly. You may have state diagrams from hell, but then, this at the end is just a state engine Well known for ages. Collections (dont even ask how old those are, concept wise) are core, as are basic data structures. Threading (not exactly new either). Nothing compared to the complexity of a real database system, or a 3d rendering system
i thought the whole idea was performance. not sure about c# collections, but java's are slow. and avoiding dynamic memory the goal
I iterate through 10,000s of collection entries multiple times per second without problems. What sort of strategies do you work with Rosy where performance requirements are so stringent as to make all the hassle of avoiding dynamic memory worth your while? If you're not involved in HFT where alpha generation opportunities only exist for milliseconds then I have yet to hear a convincing argument made by anyone as to why it is worth the hassle of dropping down to a lower level language.
Brutally sorry to ay, but that is because sun is run by idiots. The java implementation of generic collections is a freaking joke - a compiler trick, but nothing in bytecode. .NET has full generics support in the runtime at bytecode level. Overhead is absolutely minimal. No dynamic memory allocation BECAUSE of the collection - while java has boxing/unboxing everywhere out of "necessity".
The lack of struct support in Java pretty much ruled out me using it for my trading app. Having to put even the simplest data structures on the heap would have just totally killed performance. Java's only real advantage these days is that you aren't tied to Windoze.